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The  project  described  in  this  paper  was  spawned  in  a 
very  natural  way.  Only  very  recently  has  the  development 
of  the  Ada  computer  language  been  completed.  For  this 
student  of  computer  languages  lookihg  for  a  thesis 
project,  Ada  provided  an  obvious  starting  point.  The  only 
real  problem  was  in  pinpointing  the  particular  way  to  use 
Ada  in  the  thesis.  However,  since  this  writer  is  also  a 
student  of  numerical  methods,  it  was  not  hard  to  decide  on 
a  numeric  application. 

As  with  most  projects,  this  thesis  project  changed 
with  time.  It  began  with  a  simple  suggestion  from  an  AFIT 
instructor,  Capt  Richard  Conn.  He  mentioned  that  every 
language  environment  needs  to  include  routines  which 
perform  standard  math  functions,  and  he  suggested  that 
developing  such  a  unit  of  math  functions  for  Ada  would 
make  a  good  thesis  project. 

After  discussing  Capt  Conn's  suggestion  with  another 
AFIT  instructor,  Capt  Roie  Black,  the  original  thesis 
proposal  took  shape.  We  talked  about  developing  a  math 
unit  which  would  be  constructed  as  a  "package"  in  Ada.  He 
mentioned  a  preliminary  Ada  compiler  project  which  was 
then  being  completed  by  another  thesis  student,  Capt  Alan 
(Ray)  Garlington.  But  it  would  only  implement  integer  type 
numbers.  Capt  Black  suggested  that  adding  a  floating  point 
capability  to  this  compiler  would  permit  the  testing  of 
the  math  unit  during  development.  This  thesis  student 


certainly  wanted  to  be  able  to  test  what  would  be 
developed,  so  the  suggestion  was  appealing.  Hence,  the 
original  proposal  was  for  a  two-part  effort:  first,  I 
would  incorporate  the  real  (floating  point)  type  into 
Garlington's  compiler,  and  then  I  would  develop  the  math 
unit,  testing  it  with  the  compiler. 

However,  after  I  got  into  my  research,  I  began  to  see 
that  the  compiler  effort  would  take  a  great  deal  away  from 
the  actual  purpose  for  this  thesis,  and  that  no  more  than 
a  small  driver  program  would  be  required  for  the  testing  I 
would  need  to  do.  Hence,  I  decided  to  completely  decouple 
this  thesis  project  from  Garlington's  compiler.  But  this 
was  in  no  way  meant  to  take  away  from  the  compiler 
project.  To  be  sure,  the  math  unit  is  still  intended  to 
interface  with  the  compiler  later  on,  and  both  projects 
should  eventually  be  integrated  and  become  part  of  an  AFIT 
Ada  environment. 

With  both  encouragement  and  helpful  suggestions  from 
Capt  Black,  I  decided  to  make  it  possible  for  the 
precision  of  the  math  unit's  calculations  to  be  specified 
by  the  user,  or,  in  other  words,  the  unit  would  use 
arbitrary  precision.  This  then  became  the  driving  force 
for  the  thesis  project  which  emerged.  The  other  important 
emphasis  was  to  aim  for  the  Ada  goal  of  implementation 
independence.  This  was  tricky  in  the  Pascal 
implementation.  However,  I  think  I  essentially  achieved  it 
in  the  end  by  having  the  implementor  specify  the  values 


for  the  constants  to  set  the  unit  up  for  the  environment. 

I  would  like  to  express  my  appreciation  to  my  thesis 
advisor,  Capt  Black,  who  devoted  much  of  his  valuable  time 
toward  this  project,  and  who  knew  how  to  give  just  the 
right  amount  of  advice.  I  would  also  like  to  give  a 
special  thanks  to  my  good  friend  and  colleague,  Karyl 
Adams,  whose  interest  and  encouragement  sustained  me 
through  the  hard  times. 
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Abstract 

This  project  involved  designing  a  unit  of 
mathematical  functions  for  an  Ada  language  environment. 
The  design  includes  the  basic  arithmetic  operations  and 
the  transcendental  functions.  It  uses  modularity  and 
defines  both  integer  and  floating  point  number 
representations.  The  main  features  of  the  design  are  its 
use  of  any  specified  precision  (referred  to  as  arbitrary 
precision),  its  implementation  independence,  and  its 
structure  as  two  separate  Ada-like  packages.  Two  packages 
are  used  to  permit  an  implementation  to  increase  the 
unit's  efficiency,  if  desirable.  The  main  package, 
MATHPAK,  sets  up  all  of  the  unit's  functions  and  performs 
all  but  the  lowest  level  arithmetic  operations.  The 
secondary  package,  IMPLMENT,  performs  the  machine  level 
arithmetic  operations,  and  its  implementation  independent 
version  can  be  replaced  by  a  more  efficient,  machine 
dependent  package  without  requiring  changes  in  MATHPAK.  ... 

A  partial  implementation  of  the  design  was  included 
as  part  of  the  project.  This  implementation  was  written 
in  Pascal,  since  validated  Ada  environments  did  not  yet 
exist.  It  is  independent  of  any  particular  machine,  and 
it  implements  arbitrary  precision  addition  and  subtraction 
for  both  integers  and  reals. 


I. 


The  new  computer  language,  Ada,  promises  to  be  the 
most  significant  development  in  the  area  of  computer 
languages  since  the  emergence  of  the  first  high  level 
language,  Fortran,  in  the  1950s.  With  it  comes  a  new 
challenge.  Good  software  tools  are  needed  to  aid  in  the 
establishment  of  software  production  facilities  which  can 
generate  Ada  software. 

In  particular,  a  unit  of  mathematical  (math)  routines 
is  essential  to  every  language  environment. 
Traditionally,  such  math  units  have  used  the  precision  of 
the  computer  hardware  to  perform  calculations.  In  other 
words,  if  the  hardware  only  supported  60  bit  floating 
point  calculations,  then  all  floating  point  calculations 
used  60  bits.  If  both  single  and  double  precision  were 
available,  say  32  and  64  bits,  respectively,  then  users 
only  got  to  choose  between  32  and  64  bit  precision.  On 
the  other  hand,  Ada  is  designed  to  encourage  flexibility, 
and  it  allows  for  "tunable"  precision.  But  the  ultimate 
in  precision  flexibility  is  to  allow  the  user  to  define 
any  desired  precision.  This  paper  calls  this  concept 
"arbitrary  precision",  and  it  discusses  a  project  which 
designed  an  arbitrary  precision  math  unit  for  Ada. 
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Around  the  middle  of  the  last  decade,  the  Department 
of  Defense  (DoD)  realized  that  it  was  faced  with  serious 
problems  with  its  extensive  computer  software. 
Maintaining  the  software  had  become  extremely  expensive, 
but  even  at  $3.5  billion  per  year,  much  of  the  software 
was  unreliable.  Most  of  the  problems  centered  around  the 
fact  that  the  DoD  used  more  than  450  languages  in  its  wide 
variety  of  applications.  Particularly  in  the  many  weapons 
systems,  where  small  computers  are  embedded  into  the 
systems  as  integral  functional  parts,  software  maintenance 
and  reliability  were  a  nightmare.  Different  systems  used 
different  computers  and,  consequently,  different 
languages.  Thus,  general-purpose  software  tools  typically 
were  not  developed  for  embedded  systems,  and  the  normally 
tight  time  schedules  for  development  of  these  systems 
resulted  in  few  tools  of  any  kind  ever  being  developed  for 
any  of  them.  Many  systems  were  lucky  to  have  working 
compilers  in  time  to  test  the  applications  software  as  it 
was  developed.  The  result  was  many  poor  quality  systems 
with  maintenance  costs  running  higher  than  system 
development  costs  (Refs  6:7,  18:25-26,  and  29:74). 

To  solve  these  problems,  the  DoD  decided  that  it 
needed  a  common  high-order  computer  language  that  could  be 
used  for  all  embedded  software.  It  then  set  out  with  a 
refreshingly  new  approach  to  getting  such  a  language. 
After  determining  the  many  requirements  for  the  language 


and  establishing  that  no  language  meeting  those 

requirements  was  then  in  existence,  the  DoD  decided  to 

design  one  of  its  own.  But  it  did  not  just  try  to  get  a 

contractor  to  develop  the  language  with  a  low  budget  and 

tight  time  constraints.  Rather,  the  DoD  decided  to 

maintain  maximum  control  and  allow  as  much  time  as  would 

be  required  to  do  the  job  right.  It  took  the  necessary 

time  to  carefully  design  a  language  which  would  meet  all 

of  its  varied  requirements  for  embedded  software.  And  it 

went  further.  It  solicited  ideas,  criticisms,  and 

comments  from  computer  professionals  worldwide,  and  it 

revised  the  language  specifications  again  and  again  based 

on  the  feedback  received  (Refs  6:8  and  38:27). 

The  language  requirements  were  finalized  in  the 

"STEELMAN"  report  in  June  of  1978  (Ref  15) .  Then  in  July 

of  1980  the  proposed  standard  reference  manual  was 

released  (Ref  13) ,  followed  by  a  formal  definition  of  the 

language  in  November  of  the  same  year  (Ref  22) .  As  for 

the  language  described  in  these  documents,  Brender  and 

Nassi  cover  it  succinctly: 

"The  language  draws  on  many  years  of  research 
into  algorithmic  languages  and  programming 

methodology.  It  incorporates  and  directly 
supports  modern  programming  concepts  of 

abstraction  and  modularization,  separate 

compilation  of  program  units  without  loss  of 
program-wide  checking,  concurrency,  and  features 
for  efficient  systems  programming"  (Ref  5:16). 

This  language  acquired  its  name,  Ada,  late  in  its 

development.  Sources  indicate  that  Ada  was  named  after 
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who  was 


Ada  Augusta  Byron,  Countess  of  Lovelace, 
associated  with  Charles  Babbage  and  was  the  world's  first 
programmer  (Refs  37  and  38:27).  The  name,  Ada,  somehow 
perfectly  represents  the  simple,  yet  important,  purpose 
for  the  existence  of  this  language:  Ada  will  replace  all 
other  computer  languages  to  become  the  only  language  used 
for  software  in  DoD  embedded  systems. 

Because  Ada  was  designed  so  systematically  and 
because  the  DoD  is  counting  on  it  to  become  the  sole 
provider  for  so  many  critical  systems,  nothing  could  be 
left  to  chance.  Along  with  the  language  design  came 
another  set  of  DoD  requirements  for  support  environments 
for  Ada  programming.  These  also  went  through  much 
world-wide  scrutiny  and  many  revisions  before  the  final 
"STONEMAN"  document  was  released  in  February  of  1980  (Ref 
14).  Then  in  October  of  1980,  a  compiler  validation  guide 
was  published  (Ref  33)  to  aid  language  implementors  to 
insure  that  their  Ada  compilers  are  correct  according  to 
the  language  definition.  This  guide  represents  an 
extensive  effort  which  helps  to  promote  standardization 
among  language  implementations  (Ref  20) . 

With  so  much  careful  work  on  a  language  and  with  the 
existence  of  so  many  documents  defining  the  language  and 
its  environments,  it  is  not  surprising  that  the  numerics 
of  Ada  are  also  carefully  specified  and  constrained  (Refs 
13:3-8  -  3-18,  15:7  -  8,  22:3-27  -  3-36,  24:5-1  -  5-17, 

33:3-18  -  3-29,  and  37).  These  numeric  specifications, 
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and  how  they  relate  to  arbitrary  precision,  are  the  major 
concerns  of  this  thesis. 


The  Problem 

Many  projects  are  presently  underway  which  are 
working  on  the  various  aspects  of  the  Ada  software 
environment.  However,  little  has  yet  been  said  about 
producing  software  either  to  implement  the  numeric 
requirements  of  the  language  or  to  provide  necessary  math 
functions  for  use  by  Ada  programmers. 

Most  computer  programs  use  math  operations  or 
functions.  For  some,  simple  arithmetic  operations  such  as 
addition  and  multiplication  are  all  that  is  needed,  while 
for  others  exponential  or  trigonometric  (trig)  functions 
or  the  like  are  required.  Typically,  for  different 
computers  and  different  languages,  these  operations  and 
functions  are  provided  in  different  ways.  Furthermore, 
the  actual  functions  provided,  as  well  as  the  levels  of 
precision  provided  for  each,  usually  vary  greatly  from  one 
implementation  to  another. 

One  of  the  goals  of  the  Ada  design  is  to  provide 
software  portability  (Refs  15:4,  18:30,  35:19,  and  38:28). 
Portable  software  can  be  run  without  modification  on  any 
number  of  different  computers  and  will  produce  essentially 
the  same  results  on  any  one  of  them.  This  concept  calls 
for  the  development  of  implementation  independent 
software . 
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Scope 

In  keeping  with  the  Ada  goals,  the  objective  of  this 
thesis  project  is  to  design  an  implementation  independent 
unit  of  floating  point  math  functions  which  could  be  used 
in  any  Ada  environment.  The  unit  would  define  number 
representations  and  provide  all  necessary  arithmetic 
operations,  beginning  with  basic  addition,  subtraction, 
multiplication,  and  division.  Additionally,  it  would 
provide  all  the  standard  math  functions  needed  by  any 
implementation,  such  as  changing  number  representations 
and  computing  transcendental  function  values.  It  would 
work  on  a  machine  using  any  internal  precision  scheme  and 
would  use  any  desired  precision  in  its  calculations.  It 
would  also  be  expandable  so  new  functions  could  be  added 
as  found  necessary. 

Of  course,  the  ultimate  goal  of  this  project  is  to 
implement  this  design  in  an  Ada  environment.  However, 
such  a  goal  is  far  too  ambitious  for  one  masters  thesis 
project.  Hence,  the  project  described  in  this  paper  is 
the  initial  effort  of  designing  the  unit  of  math  functions 
and  implementing  the  basic  arbitrary  precision  capability 
of  the  design  to  prove  its  feasibility.  It  involves: 

1.  Designing  the  basic  structure  of  the  unit, 

2.  Researching  algorithms  for  use  in  performing  the 
various  operations  and  functions, 

3.  Determining  and  laying  out  the  number 
representations  to  be  used,  and 
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4.  Implementing  and  testing  the  basic  arbitrary 
precision  capability. 

Completing  the  implementation  of  all  the  math  functions 
will  be  left  for  a  follow-on  thesis  project. 

Assumptions 

In  laying  out  this  project,  the  assumptions  have  been 
kept  to  a  bare  minimum.  It  is  assumed  only  that  the 
machine  used  to  execute  the  math  unit: 

1.  Uses  at  least  eight  bits  (one  byte)  in  its 
internal  representation  of  an  integer  number, 

2.  Performs  the  basic  integer  operations  of 
addition,  subtraction,  multiplication,  division, 
and  modulus  on  one  word  integer  numbers, 

3.  Performs  the  basic  relational  comparisons  for 
equal,  not  equal,  less  than,  and  greater  than  for 
boolean  words,  and 

4.  Performs  the  basic  boolean  operations  of  AND,  OR, 
and  NOT  for  boolean  words. 

general  Approach 

The  Air  Force  Institute  of  Technology  (AFIT) 
presently  has  a  preliminary  Ada  compiler,  written  in 
Pascal,  which  was  designed  by  Capt  Alan  (Ray)  Garlington 
as  a  thesis  project  (Ref  19) .  Since  the  completion  of 
that  thesis  only  a  year  ago,  other  AFIT  thesis  students 
have  been  working  to  expand  its  capabilities  and  to 
produce  other  software  which  could  complement  it  in  an  Ada 
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language  environment.  The  math  unit  is  intended  to 
eventually  become  a  part  of  that  environment  as  well. 

It  would  be  most  preferable  tc  write  the  unit  in  Ada, 
since  eventually  all  Ada  software  tools  should  be  in  Ada. 
However,  since  Ada  is  so  new,  complete  and  validated  Ada 
compilers  do  not  yet  exist.  In  order  to  be  able  to  test 
the  software,  and  to  maintain  consistency  with  the 
developing  AFIT  Ada  environment,  this  first  version  of  the 
math  unit  will  be  written  in  Pascal.  But  the  design  will 
be  specifically  aimed  at  Ada  constructs,  and  the  Pascal 
implementations  will  be  as  Ada-like  as  possible.  This 
will  not  be  too  cumbersome  since  Ada  is  modeled  after 
Pascal . 


Sequence  of  Presentation 

To  begin  describing  the  development  of  this  project, 
Chapter  II  looks  at  the  project  design  and  the  modular 
structure  of  the  design  from  top  to  bottom.  It  also 
discusses  the  many  algorithms  available  in  the  literature 
for  performing  the  math  functions  of  interest  and 
considers  the  issue  of  number  representations  for 
supporting  arbitrary  precision. 

Chapter  III  is  an  in-depth  look  at  the  portion  of  the 
design  which  has  been  implemented.  In  developing  this 
software,  time  constraints  limited  the  amount  which  could 
be  completed.  However,  the  basic  structure  was  completed, 
along  with  the  modules  which  determine  the  representations 
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of  the  numbers  and  set  up  the  arbitrary  precision 
operations  on  these  numbers.  This  chapter  discusses  these 
modules  and  the  methods  used  to  make  the  unit  independent 
of  any  particular  implementation.  It  also  describes  the 
functions  laid  out  in  the  structure  and  takes  a  look  at 
testing  the  software. 

Finally,  Chapter  IV  discusses  conclusions  and 
recommendations  concerning  this  project.  Since  the 
overall  objective  was  so  ambitious,  much  hope  remains  for 
the  fucure.  The  chapter  considers  the  completion  of  the 
unit  in  Pascal  as  well  as  its  translation  into  Ada.  It 
also  looks  at  how  the  unit  may  be  used,  improved,  and 
eventually  ennanced. 
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II. 


The  design  of  this  project  reflects  the  modularity  of 
a  top-down  structured  approach.  This  chapter  looks  at  the 


design, 

starting 

with 

the  top  level 

and 

working  all 

the 

way  down 

to  the 

bottom  levels. 

It 

also  considers 

the 

various 

algorithms 

available 

for 

performing 

the 

calculations  to 

be 

implemented 

by 

this  design  and 

the 

number  representations  used  to  implement  the  arbitrary 
precision  of  the  math  unit. 

The  Structure 

With  the  top-down  design  approach,  the  first  step  was 
to  determine  the  highest  level  perspective  of  the  math 
unit,  and  design  its  interface  with  the  "outside  world". 
From  there  the  design  worked  its  way  down  through  the 
intermediate  levels  and  finished  by  determining  the 
functioning  of  the  bit  manipulations  which  occur  at  the 
very  lowest  level. 

Level .  Considering  the  entire  math  unit  as  a 
module  performing  the  abstract  function  of  transforming 
numbers,  the  first  decision  was  to  determine  how  a  user 
would  interface  with  this  module.  The  kind  of  inputs  the 
module  will  need,  and  what  it  should  output  had  to  be 
determined . 

Since  a  language  environment  is  closely  tied  to  the 
machine  used,  languages  model  the  machine.  Both  Pascal 
and  Ada  are  stack-oriented  languages  which  typically  run 
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on  stack  machines,  and  thus  they  both  model  the  machine 
memory  as  a  stack.  The  ideal  situation  is  for  the  support 
routines  of  the  environment  to  communicate  directly  with 
the  stack.  Eventually,  it  may  be  possible  for  the  math 
unit  to  use  the  physical  stack  mechanism  in  an  Ada 
environment  implemented  on  a  stack  machine.  For  now,  this 
math  unit  design  models  the  machine  in  software  as  an 
array  of  integers.  This  array  is  viewed  as  the  stack,  and 
it  is  a  useful  construct  for  handling  arguments  of 
dynamically  changing  sizes,  such  as  the  number  arguments 
of  arbitrary  precision.  The  stack  provides  the  means  for 
passing  arguments  to  and  from  the  math  unit. 

In  addition  to  the  arguments  themselves,  other 
information  needs  to  be  communicated  between  the  user  and 
the  math  unit.  Specifically ,  the  unit  needs  to  know  where 
it  can  find  the  arguments  on  the  stack  and  what  it  is 
expected  to  do  with  them.  Also,  with  arbitrary  precision, 
it  needs  to  know  the  size  of  each  argument.  The  user  then 
needs  to  know  where  to  find  the  result  on  the  stack  and  if 
any  errors  occurred  while  performing  the  calculations. 

The  most  convenient  way  to  model  the  communication  of 
precision  information  is  for  the  using  program  to  place  a 
number,  representing  the  precision,  on  the  stack  with  the 
argument.  The  unit  will  receive  both  a  stack  pointer  and 
a  function  code  as  calling  parameters  and  pass  back  both  a 
stack  pointer  and  an  error  code.  In  Pascal,  the  stack 
pointer  will  be  an  array  index  into  the  memory  stack,  and 
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the  function  code  will  be  a  number  indicating  which 
specific  function  of  the  many  provided  by  the  math  unit  is 
to  be  performed.  The  error  code  will  be  a  number 
corresponding  to  a  particular  predefined  error  message. 
The  math  unit  will  not  need  to  send  back  the  precision  of 
the  answer  since  that  can  be  determined  by  the  caller  from 
other  information. 

One  other  final  matter  at  this  top-most  level  of 
design  was  to  pick  a  name  for  this  math  unit.  Since  it 
will  correspond  to  an  Ada  "package"  construct,  it  was 
called  MATHPAK.  Thus,  MATHPAK  was  to  become  an 
implementation  independent  "package"  which  would  transform 
numbers  in  a  manner  which  still  had  to  be  determined. 

Intermediate  Levels .  Once  MATHPAK' s  interface  with 
the  outside  world  was  designed,  the  next  step  was  to  move 
to  the  next  lower  level.  This  was  the  design  of  the 
overall  structure  of  the  MATHPAK  itself. 

Still  using  the  top-down  approach,  the  MATHPAK  was 
designed  in  such  a  way  that  the  lower  level  constructs 
would  be  logical  extensions  of  the  higher  level 
constructs.  In  addition,  the  modules  in  the  MATHPAK  were 
organized  into  two  general  groups:  (1)  main  functions  and 
(2)  support  routines. 

The  main  functions  are  those  specific  MATHPAK 
functions  which  can  be  requested  by  the  user  via  the 
function  code.  The  function  code  determines  which  one  of 
these  functions  will  be  executed,  and  each  of  the 
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functions  calls  upon  specific  support  routines  to  help  it 
perform  its  function.  The  functions  are  also  organized 
into  groups,  each  group  representing  a  particular  type  of 
function.  The  groups  are: 

1.  Representation, 

2.  Arithmetic, 

3.  Exp/Log,  and 

4.  Trig. 

See  Figure  1  for  a  graphic  representation  of  the  MATHPAK 
within  the  language  environment. 

The  design  attempts  to  use  only  small  modules,  each 
of  which  performs  only  one  task.  Many  of  the  ideas  for 
designing  such  modular  software  tools  were  taken  from 
Kernighan  and  Plauger  (Ref  26)  .  T.’.e  modules  of  the 

MATHPAK  support  routines  are  its  tools.  Painstaking 
effort  has  been  put  into  trying  to  make  each  of  these 
modules  perform  its  task  in  such  a  general  way  as  to 
permit  its  use  in  more  than  just  one  specific  application. 

Looking  at  the  overall  MATHPAK  module,  it  was 
designed  to  take  in  the  function  code  calling  parameter, 
determine  which  of  its  main  functions  corresponds  to  this 
code,  execute  that  particular  function,  and  return  the 
result  of  that  execution.  MATHPAK  defines  both  the  number 
representations  to  be  used  in  the  language  environment  and 
the  manner  in  which  arithmetic  is  performed  using  them. 
Hence,  not  only  does  MATHPAK  need  to  be  able  to  do 
arithmetic  when  needed  by  a  trig  function,  for  example, 
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Figure  1.  Structure  of  the  Math  Unit 


but  it  also  needs  to  be  able  to  do  ALL  the  arithmetic 
every  program  in  the  language  environment. 


for 
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Progressing  through  successive  intermediate  levels  of 
the  design,  each  module  is  viewed  as  performing  one 
specific  task  at  that  level.  When  it  needs  to  use  lower 
level  tasks  to  accomplish  this  one  task,  it  calls  upon 
lower  level  modules  to  perform  the  lower  level  tasks.  By 
far  the  most  difficult  problem  throughout  this  effort  was 
to  maintain  generality  in  the  design  of  each  module. 

Lower  Levels .  At  the  lowest  levels  of  the  design, 
where  the  actual  number  transformations  occur,  the 
complexities  involved  with  number  representations  had  to 
be  dealt  with.  When  looking  at  bit  manipulations, 
particular  machine  characteristics  are  very  important. 
The  actual  implementation  of  the  most  basic  operations, 
such  as  division,  varies  from  one  machine  to  another.  To 
design  the  MATHPAK  with  only  one  particular  implementation 
of  such  operations  in  mind  is  to  design  in  unnecessary 
inefficiencies  for  different  machine  implementations.  If, 
for  example,  a  particular  machine  has  hardware  designed 
specifically  to  perform  division  with  a  high  degree  of 
efficiency,  there  is  no  good  reason  to  impose  artificial 
constraints  on  this  machine.  On  the  other  hand,  since 
other  machines  don't  have  such  fancy  hardware,  such  an 
implementation  can't  be  required. 

This  dilemma  was  solved  without  sacrificing  the  goal 
of  machine  independence  for  the  MATHPAK.  A  separate 
"package”,  called  IMPLMENT,  was  designed  to  perform  the 
operations  which  could  be  tailored  to  a  particular 
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implementation,  if  desired.  This  package,  like  MATHPAK, 
will  reside  in  the  language  environment,  but  only  MATHPAK 
needs  to  know  of  IMPLMENT's  existence.  The  design  of 
IMPLMENT  will  be  valid  for  any  machine,  but  the  actual 
code  could  be  changed  for  any  particular  implementation 
without  requiring  any  changes  in  MATHPAK. 

IMPLMENT  was  designed  with  the  same  top-down  approach 
as  MATHPAK.  First,  it  was  determined  that  IMPLMENT  will 
interface  with  MATHPAK  in  much  the  same  way  that  MATHPAK 
interfaces  with  the  outside  world.  Number  arguments  and 
the  precision  of  the  numbers  will  be  passed  back  and  forth 
on  the  stack.  IMPLMENT  will  receive  a  stack  pointer  and 
function  code  as  calling  parameters.  It  will  also  send 
back  a  new  stack  pointer  and  an  error  indicator  as 
parameters  of  the  call. 

IMPLMENT  also  has  the  same  general  structure  as 
MATHPAK.  At  the  top  level  its  purpose  is  to  determine 
which  of  its  main  functions  is  to  be  performed,  according 
to  the  function  code  received  as  a  calling  parameter,  and 
then  to  execute  that  function  and  return  a  result  from 
that  execution.  It  is  laid  out  in  small  modules,  each  of 
which  does  one  particular  job.  And  the  modules  are  also 
organized  into  the  same  two  groups  as  MATHPAK:  (1)  main 
functions  and  (2)  support  routines.  See  Figure  1  for  a 
graphic  representation  of  IMPLMENT  within  the  language 
envi ronment . 
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The  general  structure  of  computer  hardware  determined 
the  particular  functions  IMPLMENT  would  perform.  Although 
each  different  type  of  computer  is  unique  in  certain  ways, 
similarities  also  exist.  The  basic  instruction  sets, 
which  reflect  the  hardware  design,  all  perform  certain 
basic  operations,  although  in  different  ways  and  to 
different  extents.  As  a  basis  for  the  choice  of  functions 
for  IMPLMENT,  Osborne's  extensive  summary  of  instruction 
sets  for  various  microprocessors  (Ref  31)  was  consulted, 
as  was  this  writer's  experience  with  instruction  sets  of 
several  large  mainframe  computers.  Patterns  are  obvious, 
even  across  such  a  diverse  spectrum. 

At  the  machine  instruction  level,  all  computers 
considered  perform  much  the  same  basic  arithmetic  and 
logic  operations.  The  logic  operations  can  usually  be 
simply  and  uniformly  invoked  from  high  level  language 
constructs.  However,  the  actual  bit  manipulations 
involved  in  performing  arithmetic  generally  involves 
complex  coding  in  high  level  language  instructions,  and 
this  typically  introduces  gross  inefficiencies.  These 
basic  arithmetic  operations,  then,  are  the  functions  which 
IMPLMENT  was  designed  to  perform.  Thus,  each 
implementation  can  address  the  subject  of  the  efficiency 
of  performing  these  operations  on  its  particular  machine, 
and  each  can  produce  its  own  version  of  IMPLMENT,  if 
desired . 
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Of  course,  as  more  work  is  done  on  the  transcendental 
functions  in  MATHPAK,  additional  implementation  dependent 
requirements  could  surface.  But  IMPLMENT's  modular  design 
can  easily  handle  additional  functions  any  time  new 
developments  require  such  additions. 

Algorithms 

All  of  the  functions  in  both  MATHPAK  and  IMPLMENT  are 
implemented  by  the  execution  of  algorithms.  Much  of  the 
research  for  this  thesis  involved  finding  algorithms  for 
all  of  these  various  functions.  At  the  start  of  the 
research,  the  implementation  of  the  algorithms  was 
expected  to  be  a  part  of  this  thesis  effort.  But  as  the 
thesis  definition  changed,  it  was  evident  that  there  would 
be  little  time  to  actually  use  most  of  the  algorithms. 
However,  the  algorithm  research  stands  as  an  important 
first  step  toward  the  eventual  implementation  of  the 
MATHPAK  functions.  Hence,  outlined  below  are  the  sources 
found  in  the  research,  as  well  as  any  conclusions  which 
may  have  been  drawn  about  the  usefulness  of  the  algorithms 
discussed. 

A  good  starting  place  was  the  r.Rr.  st-andard  Mat-h 
Tables  (Ref  12) .  This  book  contains  complete  algebraic 
formulae  for  all  the  transcendental  functions,  and  it  also 
has  extensive  tables  of  values  for  these  functions.  This 
book  is  not  recommended  for  developing  the  computer 
algorithms,  since  it  does  not  in  any  way  address  computer 
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calculations.  However,  it  is  a  good  source  for 
determining  actual  values  when  testing  the  functions. 

To  find  computer  algorithms,  a  good  source  is  the 
Collected  ACU  Algorithms  (Ref  3)  whicn  contains  a  rather 
complete  list  of  algorithms  for  the  transcendental 
functions.  Some  of  the  algorithms  are  contained  in  the 
boon  itself,  while  others  are  found  in  other  sources, 
which  are  referenced  (Refs  C,  30,  ana  39).  All  of  the 
algorithms  of  interest  to  this  discussion  are  written  in 
Algol.  Since  it  is  a  clock  structured  language,  much  like 
both  Pascal  and  Ada,  these  algorithms  could  probably  oe 
translated  into  either  language  without  much  Difficulty. 
However,  other  sources  may  well  be  even  better. 

The  UiAmini  zsix.  £h£  (Ref 
10)  is  intended  as  a  complete  "cookbook"  for  implementing 
transcendental  functions  on  a  computer,  ana  it  appears  to 
have  a  Detter  approach  than  the  Algol  procedures  discussed 
auove.  The  mathematical  basis  for  its  algorithms  can  be 
founa  in  a  book  called  Computer  Approximations  (Ref  21) . 
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One  other  source  was  investigated,  and  it  led  to  an 
apparent  dead  ena.  In  Benchmark  Papers  in  Electrical 
Engineering  aHU  £Qapiii.£X  is  a  section  on  computer 
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arithmetic  which  contains  algorithms  for  calculating 
transcendental  functions  (Ref  4).  However,  the  algorithms 
discussed  here,  called  CORDIC  algorithms,  were  derived  for 
special  applications.  They  do  not  appear  to  be  useful  for 
MATHPAK  applications. 

None  of  the  sources  discussed  above  treats  arbitrary 
precision.  Typically,  an  algorithm  is  either  for  single 
or  double  precision.  The  "cookbook”  goes  a  little  farther 
and  usually  discusses  four  ranges  of  precision  levels  for 
each  function.  It  concerns  itself  with  precisions  as 
large  as  65  bits,  depending  on  the  function.  However, 
purely  arbitrary  precision  in  transcendental  function 
calculations  has  apparently  not  yet  been  addressed  in  the 
literature. 

Although  various  methods  are  used  in  the  above 
sources  for  calculating  the  transcendental  functions,  they 
are  all  similar  from  an  implementation  point  of  view.  In 
order  to  execute  these  functions  in  arbitrary  precision, 
the  math  unit  would  essentially  need  to  be  capable  of 
executing  arbitrary  precision  arithmetic  operations 
(addition,  subtraction,  multiplication,  and  division)  and 
other  arbitrary  precision  functions  which  would  be 
implemented  using  arbitrary  precision  arithmetic. 

As  for  the  basic  arithmetic  operations,  few  sources 
were  found  which  treated  this  type  of  algorithm  in  depth. 
However,  Knuth  gives  a  rather  thorough  treatment  of 
specific  algorithms  (Ref  28:180-192).  Both  Knuth  and 
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Kahan  also  give  good  general  discussions  on  algorithms  and 
floating  point  numbers.  They  treat  such  important  topics 
as  accuracy  in  floating  point  arithmetic  and  the  price 
that  must  be  paid  for  it  (Refs  25,  21,  and  28). 

Arbitrary  precision  integer  arithmetic  is,  for  the 
most  part,  a  straightforward  process  of  chaining 
machine-provided  arithmetic  operations  on  pairs  of  words. 
Raskin  used  this  type  of  technique  for  arbitrary  precision 
division  (Ref  32) ,  but  the  principle  applies  equally  well 
for  any  arithmetic  operation.  Hence,  once  any  one 
arithmetic  operation  is  implemented  for  arbitrary 
precision  integers,  the  others  would  follow  using  similar 
techniques . 

To  properly  treat  floating  point  arithmetic,  the  key 
is  to  implement  the  addition  algorithms  first.  This  holds 
for  arbitrary  precision  arithmetic  as  well  as  for  fixed 
precision,  although  the  arbitrary  precision  implementation 
is  somewhat  more  involved.  Floating  point  addition 
involves  separating  the  exponent  and  fractional  parts  of 
the  arguments  and  then  doing  numerous  shifting  operations, 
both  for  scaling  numbers  to  align  the  radix  points,  before 
adding  the  fractional  parts,  and  to  normalize  the  result 
afterward.  The  value  of  the  exponent  must  also  be  changed 
accordingly  when  shifting,  fractional  parts  must  sometimes 
be  complemented,  and  numerous  checks  for  overflow  and 
underflow  must  also  be  included  (Ref  28:182-187). 
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Once  the  addition  capabilities  are  implemented, 
subtraction  follows  immediately  and  multiplication  and 
division  are  entirely  straightforward.  For  subtraction, 
the  sign  of  the  second  argument  is  changed,  and  then 
addition  is  performed.  For  multiplication  (division) ,  the 
exponent  and  fractional  parts  are  separated,  the  exponents 
are  added  (subtracted),  the  fractional  parts  are 
multiplied  (divided) ,  and  the  result  is  normalized. 
Multiplication  and  division  of  fractional  parts  use 
machine  operations,  while  addition  and  subtraction  of 
exponents  use  the  addition  function.  Separating  the 
exponent  and  fractional  parts  and  normalizing  results  also 
use  capabilities  already  implemented  for  addition  (Ref 
28:185-190).  The  additional  capabilities  required  to  use 
arguments  of  arbitrary  precision  are  the  abilities  to  deal 
with  arbitrary  precision  representations  and  the  repeated 
execution  of  an  operation.  Clearly,  these  capabilities 
would  be  required  for  an  implementation  of  addition,  and 
they  would  thus  be  available  for  other  operations  once 
addition  is  implementetd . 

Therefore,  once  the  arbitrary  precision  integer  and 
floating  point  addition  algorithms  have  been  implemented, 
the  math  unit's  arbitrary  precision  design  will  be  proven 
valid  and  feasible.  Then  the  implementation  of  the 
remaining  arithmetic  operations  will  be  straightforward 
using  the  capabilities  already  available  for  addition. 
Similarly,  the  transcendental  functions  can  be  implemented 
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in  a  straightforward  manner  once  the  arbitrary  precision 
arithmetic  operations  are  fully  functional. 

Number  Representations 

When  looking  at  algorithms  for  the  basic  arithmetic 
operations,  the  representations  of  the  numbers  involved 
are  of  utmost  importance.  These  representations  must  also 
be  known  when  designing  the  number  representation 
routines.  So  one  of  the  design  decisions  for  MATHPAK  was 
what  representations  would  be  used,  both  for  integer  and 
floating  point  numbers. 

Since  representations  differ  for  different  computers, 
no  absolute  standards  exist  to  go  by.  And  clearly,  each 
computer  must  not  use  its  own  representations  because 
MATHPAK  and  IMPLMENT  must  be  able  to  manipulate  the  bit 
patterns  of  numbers  while  performing  their  functions.  But 
Ada  provides  specific  numeric  requirements,  so  these  have 
been  used  as  a  basis  in  determining  the  representations  to 
be  used  in  the  design. 

Ada  requires  that  a  floating  point  number  have  a 
fractional  part  between  0.5  and  1.0.  In  other  words,  the 
radix  of  the  number  must  be  2.  Another  requirement  is 
that  the  exponent  be  an  integer  in  the  range  from  -4  to  +4 
times  the  number  of  bits  in  the  fractional  part.  Floating 
point  types  can  be  declared  with  or  without  a  range  and  a 
specific  number  of  decimal  digits  D.  If  D  is  specified, 
it  corresponds  to  a  specific  minimum  number  of  binary 
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digits  (bits)  B,  where  B  is  the  integer  next  above 
D*ln(10)/ln(2)  .  D  can  also  be  made  to  correspond  to  a 
predefined  floating  point  type,  FLOAT,  LONG  FLOAT,  or 
SHORT  FLOAT.  These  types  are  just  predefined  precisions 
of  an  implementation,  and  the  specification  of  D  in  a  type 
declaration  would  just  guarantee  a  minimal  precision  when 
the  specified  type  is  made  to  correspond  to  a  predefined 
type  (Refs  13:3-14,  15:8,  22:3-31,  24:5-6,  and  33:3-20). 

The  MATHPAK  concept  of  arbitrary  precision  is 
consistent  with  these  Ada  requirements,  but  it  extends  the 
precision  possibilities  somewhat  so  that  a  specification 
of  D  can  be  made  to  correspond  to  one  of  numerous  types 
rather  than  being  limited  to  just  three.  MATHPAK' s  only 
limit  on  the  precision  of  a  number  is  the  actual  size  of 
memory  in  the  machine  being  used,  and  MATHPAK  works  with 
precision  in  one  word  increments.  In  other  words,  if  a 
user  specified  the  precision  of  a  number  to  be  longer  than 
three  words  but  shorter  than  four,  MATHPAK  will  use  four 
full  words  to  represent  the  number. 

A  series  of  Computer  magazine  articles  discussing  the 
new  floating  point  standard  proposed  by  the  Institute  of 
Electrical  and  Electronics  Engineers  (IEEE)  was  also 
consulted  when  determining  the  number  representations  for 
MATHPAK  to  use  (Refs  1,  9,  11,  and  23).  This  proposed 
standard  is  compatible  with  the  Ada  requirements,  but  it 
also  goes  into  detail  about  the  floating  point  number 
representations.  Since  this  proposal  is  compatible  with 
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Ada  and  since  it  is  the  closest  thing  to  a  floating  point 
standard,  it  was  used  as  a  basis  for  the  floating  point 
representations  for  MATHPAK.  Of  course,  since  the 
standard  does  not  apply  to  arbitrary  precision,  it  had  to 
be  modified  some.  But  Ada's  restrictions  on  the  lengths 
of  the  exponent  and  fractional  parts  of  a  floating  point 
number  made  that  modification  rather  clear-cut. 

The  floating  point  representation  used  in  MATHPAK  is 
pictured  in  Figure  2.  The  first  bit,  S,  is  the  sign  of 
the  number,  where  0  means  positive  and  1  negative.  E  is 
the  exponent,  and  its  length  is  determined  by  the  Ada 
requirement  that  the  value  of  the  exponent  must  range  from 
-4  to  +4  times  the  number  of  bits  in  the  fractional  part, 
F.  The  exponent  is  biased  by  2  raised  to  a  power  which  is 
one  less  than  the  number  of  bits  in  the  exponent.  The 
effect  of  this  bias  is  that  the  value  of  the  exponent  will 
never  be  negative,  and  thus  no  sign  bit  is  required  for 
it.  Of  course,  the  lengths  of  both  E  and  F  can  vary  as 
the  length  of  the  floating  point  number  varies. 
Therefore,  this  representation  is  valid  for  floating  point 
numbers  of  any  precision. 

As  for  integer  representations,  Ada  defines  no 
specific  requirements.  The  two's  complement  form  was 
chosen  for  integers  because  of  its  wide  usage  and  because 
it  supports  simplicity  in  calculations.  In  the  two's 


complement  form,  a  positive  integer  is  represented  by  a 
zero  sign  bit  followed  by  the  bit  pattern  for  a  binary 


Figure  2.  Floating  Point  Representation  (Ref  11:71) 


number  whose  value  is  equivalent  to  the  value  of  the  given 
integer.  A  negative  integer  representation  is  found  by 
taking  the  complement  of  the  absolute  value  of  the  integer 
and  adding  one  to  it.  Of  course,  this  results  in  a  sign 
value  of  1,  which  properly  indicates  that  the  number  is 
negative . 

Now  that  the  design  of  the  MATHPAK,  the  algorithms 
considered  for  use  in  the  design,  and  the  number 
representations  used  in  conjunction  with  the  algorithms 
have  been  considered,  it  is  time  to  look  at  the  computer 
code  implementing  the  basic  arbitrary  precision  part  of 
the  design.  This  will  be  done  in  the  next  chapter. 
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III. 


This  chapter  discusses  the  MATHPAK  and  IMPLMENT 
software  which  was  initiated  as  a  part  of  this  thesis 
project.  The  software  was  developed  on  an  Apple  II  Plus 
computer  using  Apple  Pascal,  which  is  a  dialect  of  UCSD 
Pascal  (so  named  because  it  originated  at  the  University 
of  California  at  San  Diego) .  The  Apple  II  is  an  8  bit 
machine,  but  it  performs  16  bit  integer  operations.  Thus, 
for  the  math  unit,  an  Apple  word  is  16  bits. 

It  is  not  common  to  work  at  the  bit  level  in  a  high 
level  language,  and  implementation  independence  is 
typically  an  elusive  goal  for  software.  Hence,  the 
process  of  manipulating  bits  and  the  issues  of 
implementation  independence  will  be  considered  first  in 
this  chapter.  Then  the  status  of  both  the  MATHPAK  and 
IMPLMENT  packages  as  of  the  end  of  the  work  on  this  thesis 
will  be  discussed.  Appendix  A  shows  the  structure  of  the 
presently  implemented  modules  of  MATHPAK,  and  Appendix  B 
shows  the  present  structure  of  IMPLMENT.  These  structures 
form  the  framework  on  which  future  work  on  the  math  unit 
can  be  built.  The  chapter  will  end  with  a  discussion  of 
testing.  It  will  look  at  both  what  testing  has  been  done 
and  what  will  need  to  be  done  to  prove  that  the  math  unit 
works  properly  when  the  project  is  completed. 
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Bit  Manipulations  and  ^Implementation  Independence 

Although  Pascal  is  a  rather  strongly-typed  language 
which  has  no  specific  constructs  for  bit  manipulations, 
the  language  does  provide  ways  ^for  a  programmer  to 
"tinker"  at  the  bit  level.  Pascal  records  may  contain 
variant  parts,  parts  that  are  interpreted  differently  in 
different  situations.  These  variant  parts  can  contain  tag 
fields  to  identify  how  they  are  to  be  interpreted,  in 
this  case,  the  contents  of  a  particular  record  will  always 
be  interpreted  as  compatible  with  the  tag  fields. 
However,  variant  parts  which  do  not  contain  tag  fields, 
called  free  union  variants,  are  also  legal  in  Pascal.  In 
this  case,  the  same  data  in  the  same  record  can  be 
interpreted  as  being  of  different  types  in  different 
statements  of  the  same  program  (Refs  7:454-455  and 


36:286-287) . 

Of  course,  free  union  variants  can  be  dangerous 


because  they  short-circuit  the 
type-checking  safeguards.  But  they  prov 


built-in  Pascal 


[ided  a  useful  tool 


for  this  project  because  they  permit  the  i^math  unit  to  do 
bit  manipulations.  •. 

Figure  3  is  an  example  of  a  type  declaration  which 
uses  free  union  variants.  This  is  a  portion  of  the 

IMPLMENT  code  which  declares  ARITHREG  a.4^  type  REGISTER. 

\ 

ARITHREG  is  one  machine  word  in  length.  When  performing 
integer  operations,  ARITHREG  can  be  interpreted  as  an 
integer.  However,  at  other  times  it  can  also  be 
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interpreted  as  a  boolean,  an  array  of  bytes,  or  an  array 
of  bits,  depending  upon  how  it  is  referenced.  Thus,  four 
representations  are  possible  for  the  same  contents  of 
ARITHREG. 


CONST 

LSBITNUM  =  0; 

MSBITNUM  =  15; 

BYTESIZE  =  255; 

TYPE 

REPS  =  (E,F,G,H) ; 

BITE  »  0 . .BYTESIZE; 

BYTENUMBER  =  0..1; 

BITNUMBER  =  LSBITNUM. .MSBITNUM; 

BYTEARAY  =  PACKED  ARRAY [ BYTENUMBER]  OF  BITE; 
BITARAY  =  PACKED  ARRAY [ BITNUMBER]  OF  BOOLEAN; 
REGISTER  =  RECORD  CASE  REPS  OF 
E;  (INT:  INTEGER); 

F:  (BOOL:  BOOLEAN); 

G:  (BYTE:  BYTEARAY); 

H:  (BIT:  BITARAY); 

END; 

VAR 

ARITHREG:  REGISTER; 


Figure  3.  Declaration  Using  Free  Union  Variants 

In  the  sample  code,  the  four  identifiers  in  REPS  are 
just  dummy  declarations  needed  to  show  that  four  variant 
types  will  be  declared.  The  identifiers  which  are  used  in 
the  program  to  select  the  desired  representations  are  the 
descriptive  terms  INT,  BOOL,  BYTE,  and  BIT.  Hence, 
ARITHREG. INT  refers  to  an  integer.  Similarly, 
ARITHREG. BIT [MSBITNUM]  refers  only  to  the  most  significant 
bit  of  ARITHREG  and  it  is  operated  on  as  a  boolean  value. 
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The  numbers  declared  as  constants  in  Figure  3  are 
specific  for  the  Apple  II.  These  specific  numbers  are  in 
the  constant  declarations  so  they  may  be  changed  for 
different  implementations  without  requiring  other  changes 
to  the  IMPLMENT  package.  For  this  Apple  implementation,  a 
word  has  16  bits,  numbered  15  to  0  from  most  to  least 
significant.  The  two  half-words  (BITEs)  are  numbered  1 
and  0  for  most  and  least  significant,  respectively.  BITE 
is  declared  as  an  integer  in  the  range  from  0  to  the 
largest  number  which  can  be  held  in  half  a  word,  which,  in 
this  case,  is  255.  Since  this  value  needs  exactly  one 
half  word,  a  packed  array  of  BITEs  uses  exactly  one  word 
(as  does  an  integer,  a  boolean,  and  a  packed  array  of  16 
bits)  . 

Although  care  has  been  taken  to  make  the  Pascal 
version  of  both  MATHPAK  and  IMPLMENT  implementation 
independent,  reservations  must  be  stated  in  this  respect. 
First  of  all,  each  package  requires  that  the  constants  be 
set  for  the  implementation,  so  a  change  is  required  for 
each  implementation,  but  it  can  be  done  easily.  Even 
after  setting  the  constants,  however,  with  the  rather 
tricky  bit  manipulations  performed  by  portions  of  the 
code,  complete  machine  independence  still  cannot  be 
guaranteed. 

Most  computer  languages  have  numerous  dialects,  and 
Pascal  is  no  exception.  Throughout  MATHPAK,  either  the 
Pascal  dialect  which  meets  the  proposed  standard  of  the 
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International  Standards  Organization  (ISO)  has  been  used, 
or  else  the  documentation  for  the  non-standard  module 
states  what  work  is  required  to  make  the  final  version 
meet  the  ISO  standard.  Tiberghien's  The  Pas cai  Handbook 
(Ref  36)  is  the  authority  which  has  been  used  to  determine 
the  correct  usage  of  ISO  Standard  Pascal.  But  to  the 
extent  that  the  free  union  variant  constructs  of  ISO 
Standard  Pascal  can't  be  executed  in  the  environment  of 
other  dialects,  the  chances  of  MATHPAK  and  IMPLMENT 
working  without  modification  diminish. 

Another  possible  problem  is  that  one  characteristic 
of  booleans  which  has  been  taken  advantage  of  in  the 
Pascal  code  of  this  project  could  possibly  work 
differently  on  other  machines  than  on  the  Apple.  Boolean 
operators  are  usually  assumed  to  perform  single  TRUE  and 
FALSE  operations  on  only  the  least  significant  bit  in  a 
word.  However,  on  the  Apple,  boolean  operations  are 
performed  bitwise  on  all  16  bits  of  the  operands,  and  this 
fact  has  been  used  in  some  of  the  boolean  operations 
performed  in  the  packages.  Therefore,  these  packages 
would  not  execute  correctly  should  they  be  run  on  a 
machine  which  works  differently  with  booleans. 

Before  leaving  the  subject  of  bit  manipulations,  some 
comments  need  to  be  made  about  doing  these  same  bit 
manipulations  in  Ada.  Since  one  of  Ada's  design  criteria 
was  for  it  to  be  able  to  handle  systems  software,  Ada  has 
specifically  designed  ways  to  handle  bit  manipulations . 
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These  are  much  less  awkward  and  far  more  obvious  than  the 
methods  which  have  been  used  in  Pascal.  Hence,  when  the 
Pascal  code  is  translated  to  Ada,  one  will  not  have  to 
resort  to  unsafe  "tricks"  as  in  Pascal  (Refs  13:1-1, 
17:18-23,  22:1-1,  and  34:29,80). 

The  Ada  designers  have  also  gone  to  great  lengths  to 
make  sure  the  language  is  completely  standardized  and 
independent  of  any  implementation  (Refs  15:21  and 
17:49-51).  Hence,  to  the  extent  that  this  standardization 
is  achieved,  the  math  unit  in  Ada  should  have  no  problem 
with  different  language  dialects  causing  deterioration  of 
the  goal  of  implementation  independence. 

MATHPAK 

This  section,  will  look  at  the  presently  implemented 
form  of  MATHPAK  in  some  detail.  The  reader  can  refer  to 
Appendix  A  for  an  overall  picture  of  the  structure  of  the 
MATHPAK  modules  and  to  Appendix  C  for  a  complete  listing 
of  the  MATHPAK  to  its  present  point  of  completion. 

In  the  declarations  of  the  MATHPAK  listed  in  Appendix 
C,  the  constants  are  set  to  the  correct  values  for  an 
Apple  II  implementation.  These  constants  provide  the 
means  for  setting  up  the  MATHPAK  for  any  particular 
implementation,  and  they  permit  the  remainder  of  th£ 
MATHPAK  code  to  be  independent  of  the  implementation. 
With  this  set-up,  any  time  MATHPAK  is  implemented  in  a  new 
environment,  these  constants  must  be  set  to  correspond  to 
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that  environment.  They  tell  MATHPAK  the  machine  wordsize, 
how  the  bits  are  numbered  in  a  word,  how  the  global  memory 
stack  will  be  built  in  this  environment  (high  to  low 
memory  or  vice  versa) ,  and  the  maximum  size  allowable  for 
a  number  in  this  environment.  Once  this  is  done,  MATHPAK 
can  be  compiled,  and  it's  ready  to  go. 

MATHPAK  declares  some  free  union  variant  records,  as 
described  in  the  previous  section.  One  of  these  is  an 
array  of  three  numbers  which  MATHPAK  uses  as  a  work  area 
to  perform  bit  manipulations  on  arguments.  Each  of  these 
is  the  maximum  allowable  size  for  a  number  in  this 
environment.  Note,  however,  that  such  a  large  work  area 
would  not  be  necessary  if  MATHPAK  could  do  bit 
manipulations  on  the  stack.  In  a  later  Ada  version,  if 
MATHPAK  can  communicate  directly  with  the  machine  memory 
stack,  this  separate  large  work  area  would  not  be 
necessary . 

MATHPAK  also  uses  a  free  union  variant  record  to  set 
up  an  array  of  masks.  These  are  used  for  masking  to 
ensure  that  only  the  desired  bits  of  a  word  are  changed 
when  MATHPAK  writes  bit  values  to  words  in  the  work  area. 
The  masking  is  not  necessary  in  the  Apple  UCSD  Pascal  used 
for  the  MATHPAK  development,  but  it  is  necessary  for  a 
Standard  Pascal  implementation. 

MATHPAK 's  main  functions  are  those  which  can  be 
requested  by  the  calling  program  via  the  function  code. 
The  transcendental  functions  are  not  yet  operational,  but 
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most  of  the  number  representation  functions  are  complete 
and  the  functions  which  perform  arithmetic  operations  for 
arbitrary  precision  are  fully  operational  (see  Appendix 
A) .  The  most  important  arithmetic  operation  to  develop 
for  this  math  unit  was  addition.  It  is  the  most  complex 
of  the  operations  to  implement,  and  it  establishes  the 
basis  for  the  other  operations  because  the  others  perform 
steps  which  must  be  developed  for  addition  (Ref  28:187). 
Arbitrary  precision  addition  is  completely  operational  for 
both  integers  and  floating  point  numbers,  and,  with  this, 
the  design  of  the  math  unit  has  been  proven  valid  and 
feasible.  See  the  section  on  Algorithms  in  Chapter  II  for 
a  more  detailed  discussion  of  this  point.  With  the 
completion  of  addition,  subtraction  was  also  easily 
completed  as  the  addition  of  the  inverse  of  the  second 
argument.  Time  did  not  permit  the  completion  of 
multiplication  and  division  as  a  part  of  this  effort. 
Although  their  implementation  is  straightforward  now  that 
addition  is  operational,  they  each  require  the  integration 
of  several  steps,  and  this  is  considerably  more 
time-consuming  than  the  one-step  effort  required  to 
complete  subtraction  using  addition. 

All  of  the  MATHPAK  functions  are  described  in  Tables 
I  through  IV.  Each  of  the  tables  lists  the  functions  for 
one  of  MATHPAK' s  groups  of  functions,  and  in  each  of  these 
tables,  INT  refers  to  an  integer  type  and  REL  to  a 
floating  point  (real)  type.  Also,  for  groups  of  functions 
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with  names  that  differ  only  by  I  and/or  R  at  the  end  of 
the  name,  I  refers  to  an  integer  argument  and  R  to  a  real 


argument.  If  a  name  has  two  of  these  letters  at  the  end, 
the  function  takes  two  arguments  in  the  order  indicated  by 
the  letters.  Where  a  function  takes  both  an  integer  and  a 
real  argument,  the  result  is  always  real. 

Table  I  describes  the  names  and  tasks  of  the 
Representation  Functions.  Each  of  these  can  perform  a 
change  in  the  representation  of  a  numerical  argument  of 
the  correct  type. 


Table  I 

Description  of  MATHPAK's  Representation  Functions 


Name 

Function 

FLOAT 

Change  a  number  from  one  representation 

RELTOINT 

... 

to  another 

I NTS I Z EC HANG E 
RELSIZECHANGE 

Change  the  precision  of  a  number 

ABSVALI 

Replace  a  number  by  its  absolute 

ABSVALR 

value 

In  Table  II,  the  Arithmetic  Functions,  which  perform 
all  of  the  basic  arithmetic  operations  usually  associated 
with  the  +  ,  -,  *,  and  /  symbols,  are  named  and  defined. 
All  of  these  functions  yield  a  result  of  the  same  type  as 
their  input  arguments,  unless  integers  and  reals  are 
mixed,  and  then,  as  stated  above,  the  result  is  real. 
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Table  II 


Description  of  MATHPAK's  Arithmetic  Functions 


Name 

Function 

PLUSH 

PLUSRR 

PLUSIR 

PLUSRI 

Add  two  arguments 

PLUSI 

PLUSR 

The  identity  operation  which  returns 
the  argument  unchanged 

MINUSII 

MINUSRR 

MINUSIR 

MINUSRI 

Subtract  the  second  argument  from 
the  first 

MINUSI 

MINUSR 

Negate  the  argument 

MULTI I 

MULTRR 

MULTIR 

MULTRI 

Multiply  two  arguments 

DIVII 

DIVRR 

DIVIR 

DIVRI 

Divide  the  first  argument  by 
the  second 

REM  I 

Divides  the  first  integer  by  the 
second  and  returns  the  remainder 

MODI 

Finds  the  modulus  of  the  first 
integer  by  the  second 

Table  III  shows  the  Exp/Log  Functions,  which  include 
all  functions  associated  with  exponentiation  and 
logarithms.  The  power  functions,  each  using  two 
arguments,  yield  a  real  result  if  types  are  mixed,  and 
otherwise  the  result  is  of  the  same  type  as  the  input 
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arguments.  The  remaining  functions  in  this  group  all  take 
one  argument  and  all  yield  a  real  result. 


Table  III 

Description  of  MATHPAK's  Exp/Log  Functions 


r 

Name 

Function 

POWERII 

Performs  exponentiation  using  the 

POWERRR 

first  argument  as  the  base  and 

POWERIR 

POWERRI 

the  second  as  the  exponent 

SQRTI 

SQRTR 

Finds  the  square  root  of  the  argument 

EXPI 

Performs  exponentiation  using  e  as  a 

EXPR 

base  and  the  argument  as  the  exponent 

LOG  I 

Finds  the  base  10  logarithm  of  the 

LOGR 

argument 

LNI 

Finds  the  base  e  logarithm  (natural 

LNR 

log)  of  the  argument 

The  Trig  Functions  are  defined  in  Table  IV,  and  each 
of  these  yields  a  real  result.  Functions  using  the  trig 
functions  cotangent,  secant,  or  cosecant  have  not  been 
included  because  these  can  be  easily  calculated  from  the 
tangent,  cosine,  and  sine  functions,  respectively. 

The  support  routines  are  the  modules  which 
perform  the  lower  level  tasks  called  for  by  the  main 
functions.  Many  general  support  routines  have  been 
implemented,  and  most  of  these  will  also  be  used  to  make 
the  remaining  main  functions  operational.  These  general 


Table  IV 


Description  of  MATHPAK's  Trig  Functions 


Name 

Function 

SINI 

SINR 

Finds  the  sine  of  the  argument 

COS  I 

COSR 

Finds  the  cosine  of  the  argument 

TAN  I 

TANR 

Finds  the  tangent  of  the  argument 

ARCSINI 

ARCSINR 

Finds  the  number  whose  sine  is 
the  argument 

ARCCOSI 

ARCCOSR 

Finds  the  number  whose  cosine  is 
the  argument 

ARCTANI 

ARCTANR 

Finds  the  number  whose  tangent  is 
the  argument 

SINHI 

SINHR 

Finds  the  hyperbolic  sine  of  the 
argument 

COSHI 

COSHR 

Finds  the  hyperbolic  cosine  of  the 
argument 

TANHI 

TANHR 

Finds  the  hyperbolic  tangent  of  the 
argument 

routines,  and  the  types  of  tasks  performed  by  each,  are 
described  briefly  in  Table  V. 

IMPLMENT 

The  original  conception  of  IMPLMENT  was  as  a  module 
that  had  to  be  machine  dependent  and  would  probably  need 
to  be  written  in  machine  language.  IMPLMENT  must  know 
when  a  carry  or  an  overflow  occur,  for  example,  and  to  get 
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Table  V 


Description  of  MATHPAK's  Support  Routines 


Name 

Task 

INITMASKS 

Initialize  bit  masks 

POPARG 

PUSHARG 

Transfer  arguments  to  and  from 
the  stack 

WRITEVAL 

WR1TEBIT 

BITVALFILL 

BITSTOBITS 

COPYEXPO 

Transfer  bit  values 

GETSTATZERO 

Check  for  a  zero  argument 

GETNEWSIZE 

SETWORDS 

EXPOSIZE 

CHECKEXPO 

Calculate  and  check  sizes  of 
arguments  and  exponents 

CHKHIWORD END 
CHKLOWORD  END 

Adjust  word  and  bit  index  values 
at  word  boundaries 

SHIFTRIGHT 

SHIFTLEFT 

Shift  a  given  number  of  bits  over 
a  given  number  of  bits 

1 

INTBITREP 

RELBITREP 

Prepares  arguments  in  work  area 

COMPLMENT 

ABSVALINT 

Negate  number  representation 

SAMEINTPRECISION 
SAMERELPREC I S I ON 
INTDECREASE 
RELDECREASE 

Adjust  the  size  of  arguments 
and  exponents 

ADDARGS 

Add  arguments  via  IMPLMENT 

FINDNONOBIT 

FIND1STFRACBIT 

Determine  bits  to  be  used  for 
representation  changes 

POWEROF 

CALCEXPO 

Make  exponent  calculations 

that  type  cf  information,  it  seemed  necessary  for  IMPLMENT 
to  get  at  the  Apple's  status  register  (Refs  2:12  and 
16:120).  The  thought  of  doing  any  part  of  this  project  in 
machine  language  was  not  very  attractive,  however. 
IMPLMENT  efficiency  was  not  the  main  concern  in  this 
thesis  effort.  The  main  concern  was  the  project  goal, 
which  was  to  design  an  implementation  independent  math 
unit  and  implement  the  basic  arbitrary  precision  to  prove 
the  design's  feasibility.  In  that  light,  a  machine 
dependent  IMPLMENT  would  be  a  necessary  evil  at  best,  for 
it  would  be  needed  to  implement  arbitrary  precision,  but 
it  would  not  be  part  of  a  machine  independent 
implementation . 

After  some  thought,  however,  a  better  idea  was 
conceived.  If  the  arithmetic  operations  were  done  using 


only 

half 

a  word 

at  a 

time , 

IMPLMENT  would 

be  able 

to 

"see 

"  carries. 

using 

the 

same 

Pascal 

bit 

"tricks" 

that 

were 

used 

in  MATHPAK. 

And 

bits 

could 

be 

examined 

to 

determine  overflows  and  underflows  and  the  like.  Hence, 
IMPLMENT  could  be  done  independent  of  the  Apple,  and  it 
could  be  viewed  as  an  integral  part  of  the  effort  to 
produce  an  implementation  independent  math  unit.  Yet,  at 
the  same  time,  implementors  would  be  able  to  replace  this 
version  of  IMPLMENT,  if  desired,  with  one  which  could 
produce  more  efficiency  for  their  particular  situation. 
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The  present  form  of  IMPLMENT  completes  the 

implementation  of  arbitrary  precision  addition  and 


subtraction  in  the  math  unit.  Of  the  large  number  of 
support  modules  which  have  been  implemented,  most  will 
also  be  used  to  support  the  multiplication  and  division 
functions,  when  they  are  completed.  The  reader  can  refer 
to  Appendix  B  for  an  overall  picture  of  the  structure  of 
the  present  modules  in  IMPLMENT  and  Appendix  D  for  a 
complete  listing  of  IMPLMENT  to  its  present  point  of 
completion . 

IMPLMENT  is  structured  very  much  like  MATHPAK.  In 
its  declarations  in  the  listing  in  Appendix  D,  the 
constants  are  presently  set  to  the  correct  values  for  an 
Apple  II  implementation,  and  once  again,  these  constants 
can  be  changed  to  correspond  to  a  new  environment  for  a 
new  implementation.  This  feature  permits  the  remainder  of 
IMPLMENT  to  be  as  independent  of  the  implementation  as 
MATHPAK . 

Types  have  been  declared  using  the  free  union  variant 
records  in  much  the  same  manner  as  in  MATHPAK.  The 
variables  of  type  REGISTER  act  much  like  the  registers  of 
the  machine  (see  Figure  3  for  a  complete  declaration  of 
type  REGISTER) .  They  are  used  to  actually  perform 


arithmetic  operations.  As  with  the  MATHPAK,  IMPLMENT  also 
has  declared  large  work  areas,  which  would  not  be 
necessary  if  bit  manipulations  could  be  done  on  the  stack. 


Table  VI 

Description  of  IMPLMENT's  Main  Functions 


Name 

Function 

I NT ADD 

Adds  two  arguments 

RELADD 

INTMULT 

RELMULT 

Multiplies  two  arguments 

INTDIV 

Divides  the  first  argument  by 

RELDIV 

the  second 

IMPLMENT  presently  has  six  main  functions.  However, 
more  may  well  be  found  necessary  as  MATHPAK's  functions 
are  completed.  Of  the  present  main  functions,  only  two 
are  completed  (See  Appendix  B) .  These  use  algorithms  and 
ideas  from  Knuth  (Ref  28:180-187)  to  complete  the  MATHPAK 
addition  functions  and  make  arbitrary  precision  addition 
and  subtraction  operational  for  the  math  unit.  All  of 
IMPLMENT's  main  functions  are  listed  in  Table  VI.  Each  of 
these  functions  takes  two  arguments  of  the  same  type  (INT 
for  integer  and  REL  for  real)  and  yields  a  result  of  that 
type.  Note  that  subtraction  is  not  included  in  IMPLMENT's 
functions  because  a  subtraction  operation  in  MATHPAK  will 
always  be  turned  into  an  addition  operation  before 
IMPLMENT  is  called.  However,  division  is  included  because 
turning  a  division  operation  into  multiplication  is  not 
usually  desirable  in  computer  arithmetic. 
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IMPLMENT  has  numerous  support  routines,  and  these 
perform  many  basic  tasks.  Again,  structured  much  like 
MATHPAK,  IMPLMENT  already  contains  the  key  modules  which 
will  be  used  by  the  multiplication  and  division  functions 
when  they  are  completed.  These  modules,  and  the  types  of 
tasks  each  performs,  are  described  briefly  in  Table  VII. 
Note  that  these  modules  perform  much  the  same  types  of 
basic  tasks  as  the  support  routines  in  MATHPAK. 

Testing 

At  this  point  in  the  development  of  the  math  unit, 
only  preliminary  testing  has  been  done.  However,  as  the 
development  continues,  much  more  testing  will  be  required 
before  the  unit  can  be  considered  finished.  This  section 
outlines  what  type  of  testing  has  been  done  and  what  will 
need  to  be  done  in  the  future. 

Only  a  few  of  the  MATHPAK  functions  actually  perform 
their  complete  functions  at  this  time,  and  testing  to  this 
point  has  naturally  centered  around  these.  Through  this 
testing,  however,  every  presently  completed  module  in  both 
MATHPAK  and  IMPLMENT  have  been  used  to  some  extent.  Just 
by  doing  "simple"  addition  and  subtraction  of  various 
pairs  of  numbers,  every  module  has  been  called  and 
"exercised".  This  does  not  necessarily  mean  they  all  work 
perfectly,  but  it  does  mean  they  all  work  properly  under 
many  different  sets  of  circumstances. 
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Table  VII 


Description  of  IMPLMENT's  Support  Routines 


Name 

Task 

SIGNINTADD 

Checks  signs  of  arguments 

ADDGENERAL 

Adds  two  arguments 

INTPREPADD 

RELFRACADDPREP 

RELEXPADDPREP 

Prepares  arguments  in  work  area 

CHKHIWRDEND 

CHKLOWRDEND 

Adjust  word  and  bit  index  values  at 
word  boundaries 

RIGHTSHIFT 

LEFTSHIFT 

NORMLEFTSHIFT 

ADDNORMALIZE 

Shift  a  given  number  of  bits  over 
a  given  number  of  bits 

EXPFROMNUMBER 

ZEROOUTEXP 

EXPTONUMBER 

Transfer  bit  values 

EXPSIZE 

DECEXP 

CARRY ONMSB 

Calculate  and  check  size  of 
exponent 

ARGTOWORKAREA 

WRKAREATOSTACK 

PUSHRESULT 

Transfer  arguments  to  and  from 
the  stack 

COMPLEMENT 

Negate  number  representation 

CHKINTADD 

CHKRELADD 

Check  for  errors  in  addition 
and  make  necessary  adjustments  to 
representation  of  result 

MASKINIT 

Initialize  bit  masks 

A  small  driver  program  was  used  for  the  preliminary 
testing.  It  read  an  input  file  to  get  sets  of  numbers  for 
setting  up  an  environment  and  providing  input  arguments. 


It  then  immediately  wrote  out  all  the  input  information 
for  verification,  and  it  also  wrote  out  the  bit  patterns 
of  all  the  input  arguments.  Next,  it  loaded  the  stack 
with  one  pair  of  input  arguments  at  a  time  and  called 

MATHPAK  to  add  them,  using  the  proper  calling  parameters 

for  that  particular  test.  After  MATHPAK  was  finished  and 
the  driver  got  control  again,  it  wrote  out  the  bit  pattern 
of  the  result  as  well  as  an  error  message,  either 
indicating  that  no  error  had  occurred  or  describing  the 
type  of  error  that  was  detected  during  the  MATHPAK 

execution . 

Additionally,  write  statements  were  placed  at  the 
beginning  of  each  module  to  verify  when  each  was  called, 
and  several  write  routines  were  also  incorporated  into 
both  MATHPAK  and  IMPLMENT  for  testing  purposes.  With 
these,  output  was  produced  which  "walked  through"  the 
execution,  showing  what  modules  were  executed  in  what 
order  and  writing  out  the  bit  pattern  of  intermediate 

results  at  critical  points  along  the  way. 

Several  different  combinations  of  numbers  were  used 
in  the  testing  to  verify  that  the  completed  functions  are 
working  correctly.  The  tests  included  adding  and 

subtracting  the  following  combinations  of  numbers: 

1.  Both  numbers  were  of  one  word  precision. 

2.  Both  numbers  were  of  the  same  large  precision. 

3.  The  numbers  were  of  different  precisions. 

4.  Both  numbers  were  positive. 
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5.  Both  numbers  were  negative. 

6.  The  numbers  had  opposite  signs. 

7.  Both  numbers  were  integers. 

8.  Both  numbers  were  real. 

9.  One  number  was  real  and  the  other  an  integer. 

10.  The  numbers  were  of  significantly  different 

magnitudes . 

The  tests  also  included  instances  where  integers  were 
changed  to  reals  and  carries  were  performed  over  half-word 
and  word  boundaries.  Under  all  of  the  above  conditions, 
the  presently  completed  MATHPAK  and  IMPLMENT  modules  seem 
to  be  working  properly. 

As  the  development  of  the  math  unit  continues,  the 
type  of  testing  done  so  far  will  need  to  continue.  When 
the  functions  to  be  tested  get  above  the  level  of  simple 
arithmetic,  it  will  become  necessary  to  check  the  outputs 
against  some  authoritative  source,  such  as  the  entries  in 
the  CRC  st-andard  Mathematical  Tables  (Ref  12).  However, 
additional  sources  will  be  required  to  verify  calculations 
for  numbers  of  large  precision. 

In  addition  to  this  preliminary  type  of  testing  which 
is  done  with  a  test  driver  program,  the  math  unit  must 
also  be  integrated  into  a  language  environment  before 
testing  is  completed.  It  is  expected  that  this  will  be 
done  in  an  environment  available  at  AFIT,  and  the  math 
unit  can  then  be  interfaced  with  Garlington's  compiler. 
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In  Pascal,  the  math  unit  will  actually  become  an 
integral  part  of  the  compiler  because  the  compiler  will 
have  to  know  all  of  MATHPAK's  function  codes  to  be  able  to 
properly  set  up  calls  to  the  package.  MATHPAK  will  also 
be  used  to  perform  all  of  the  compiler's  arithmetic. 
Additionally,  the  input  and  output  routines  of  the 
environment  will  have  to  be  able  to  deal  with  arbitrary 
precision  numbers.  They  will  probably  also  use  some  of 
MATHPAK's  functions,  particularly  the  representation 
functions,  to  assist  in  their  tasks. 

In  Ada,  where  MATHPAK  and  IMPLMENT  will  actually  be 
implemented  as  packages,  the  compiler  will  probably  not 
need  to  know  quite  so  much  about  MATHPAK.  Users  should  be 
able  to  call  for  MATHPAK  functions  directly  by  using  names 
set  up  in  MATHPAK  (probably  generic  names) .  With  this  new 
concept,  and  since  Ada  allows  arithmetic  operators  to  be 
defined  as  functions  too  (Refs  13:6-9  -  6-10,  22:6-20 

6-21) ,  MATHPAK  may  not  need  to  be  such  an  integral  part  of 
the  compiler.  A  looser  interface  may  be  better.  Actual 
experience  with  Ada  environments  will  be  needed  to 
determine  the  best  interface. 

After  complete  testing  with  several  different  types 
of  programs  in  the  language  environment,  the  math  unit 
will  be  ready  for  conditional  acceptance  into  the 
environment.  Only  an  incurable  optimist  would  not  expect 
little  bugs  to  be  found  now  and  then  later  on,  but  these 
could  be  handled  as  improvements  for  later  versions. 
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Now  that  the  reader  has  seen  how  the  unit  was 
conceived,  designed,  and  partially  implemented,  it  is  time 
to  discuss  conclusions  and  recommendations.  This  will  be 
done  in  the  next,  and  final,  chapter. 
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Although  the  math  unit  is  not  yet  completely 
implemented,  some  important  conclusions  can  be  drawn  at 
this  point.  Numerous  recommendations  can  also  be  made  for 
the  future  of  the  math  unit.  This  future  includes  the 
completion  of  the  unit's  modules,  both  in  Pascal  and  in 
Ada,  the  use  of  the  unit  in  language  environments,  and 
improvements  and  enhancements  which  can  be  made  later  on. 

Completion 

Before  any  real  use  can  be  made  of  this  project,  its 
present  form  must  be  completed.  This  means  accomplishing 
several  things: 

1.  Selecting  algorithms  for  the  incomplete 
functions.  The  algorithm  discussion  in  Chapter 
II  should  be  most  helpful  to  this  end. 

2.  Implementing  the  selected  algorithms  in  Pascal. 
Many  of  the  present  support  routines  will  be 
useful  when  doing  this. 

3.  Completing  the  necessary  revisions  to  ensure  that 
the  code  is  in  ISO  Standard  Pascal.  The  modules 
that  need  revisions  contain  documentation 
describing  what  needs  to  be  done. 

4.  Analyzing  possible  errors,  and  completing  the 
unit's  error  processing  capabilities.  Much 
remains  to  be  done  in  this  area,  particularly  in 
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5.  Completely  testing  all  main  functions  to  ensure 
proper  performance.  This  is  an  extension  of  the 
preliminary  testing  already  done. 

6.  Integrating  the  unit  into  the  environment  of  at 
least  one  operational  system.  Several  of  the 
systems  available  at  AFIT  would  provide  good 
proving  grounds.  The  Avionics  Laboratory  at 
Wright-Patterson  AFB,  which  presently  sponsors 
Ada  thesis  efforts,  makes  a  DEC  10  environment 
available  to  AFIT  for  such  development  work.  A 
CDC  6600  is  also  available  for  AFIT  use,  and  AFIT 
has  its  own  VAX  system  which  could  also  support 
this  work.  Of  course,  the  entire  AFIT  Ada 
environment  would  have  to  be  integrated  into  the 
system  for  this  type  of  testing. 

Completion  also  means  more  than  just  completing  the 
present  form  of  the  math  unit.  It  means  translating  the 
unit  into  Ada  to  complete  the  long-term  goal  of  this 
project.  This  means  accomplishing  several  additional 
items: 

1.  Modifying  the  design,  as  necessary,  to  take 
advantage  of  Ada  constructs.  These  modifications 
should  not  affect  the  overall  structure,  but  they 
will  affect  the  specifics  of  how  each  objective 
in  the  design  is  accomplished. 

2.  Writing  the  Ada  code.  This  can  be  thought  of  as 
a  translation  from  Pascal,  since  the  structure  of 
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the  code  in  each  language  should  be  basically  the 
same.  Changing  MATHPAK  and  IMPLMENT  from  Pascal 
procedures  to  Ada  packages  will  produce  a  need  to 
make  some  changes  to  the  method  of  interfacing 
them  both  with  user  programs  and  with  each  other. 
The  error  processing  will  also  change 
significantly  with  the  use  of  error  handlers  for 
exception  processing  in  Ada.  However,  the 
overall  function  of  the  two  packages  and  the 
information  they  exchange  with  user  programs  and 
with  each  other  remain  the  same. 

3.  Completely  testing  all  functions  to  ensure  proper 
performance.  Once  again,  this  is  the  preliminary 
testing  of  the  code. 

4.  Integrating  the  unit  into  at  least  one 
operational  Ada  language  environment  written  in 
Ada.  This  would  most  likely  be  accomplished  when 
the  entire  AFIT  Ada  environment  is  "translated" 
into  Ada.  However,  when  its  Ada  code  is 
completed  and  fully  tested,  the  math  unit  could 
be  implemented  in  any  Ada  environment. 


Use. 

The  math  unit  could  eventually  play  an  important  role 
in  the  development  of  good  software  systems  for  the  DoD. 
This  project  has  created  a  design  and  enough  of  a  Pascal 
implementation  to  prove  the  feasibility  of  the  design. 
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The  design  could,  when  completed,  prove  useful  in  many 
Pascal  environments.  More  than  that,  however,  this  math 
unit  could  provide  a  powerful  tool  in  the  Ada  language 
environments  provided  for  many  future  DoD  software 
development  efforts. 

When  all  the  functions  called  for  in  the  present 
design  are  completed  and  proper  testing  has  been  done,  the 
math  unit  could  be  implemented  in  a  Pascal  environment. 
As  with  integrating  it  into  Garlington's  Ada  compiler,  the 
unit  would  have  to  be  integrated  with  the  Pascal  compiler, 
and  this  would  require  some  work  on  proper  interfacing. 
In  particular,  the  compiler  would  have  to  be  made  aware  of 
MATHPAK's  existence,  it  would  have  to  know  MATHPAK's 
function  codes,  and  it  would  have  to  declare  a  memory 
stack  structure  corresponding  to  the  one  MATHPAK  expects 
to  find.  The  system  input  and  output  routines  would  also 
have  to  be  modified  to  read  and  write  numbers  of  arbitrary 
precision  to  and  from  the  necessary  number  representations 
used  by  MATHPAK. 

This  implementation  could  be  done  in  a  Pascal 
environment  at  AFIT.  In  addition  to  being  a  good  place  to 
test  the  math  unit,  AFIT  is  also  a  likely  math  unit  user. 
The  unit  would  provide  an  excellent  tool  for  the 
engineering  applications  dealt  with  there,  and  the 
students  would  provide  excellent  feedback  on  how  well  the 
unit  performs,  as  well  as  what  improvements  could  be 
considered.  Hence,  a  Pascal  implementation  would  be  worth 
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consideration,  especially  at  AFIT. 

It  is  also  expected  that  once  the  AFIT  Ada 
environment  is  integrated  into  one  or  more  systems  at 
AFIT,  it  will  remain  there  to  be  used.  This  environment 
could  eventually  be  expanded  to  a  completely  validated  Ada 
operating  environment,  either  entirely  through  research 
done  at  AFIT  or  through  combining  the  software  developed 
at  AFIT  with  other  software  developed  elsewhere  for  Ada 
language  environments. 

In  the  long  run,  the  Ada  version  of  the  math  unit 
could  be  implemented  in  other  DoD  Ada  environments.  If 
the  unit's  usefulness  can  be  confirmed,  then  it  could  be 
put  to  use  throughout  the  DoD,  providing  a  powerful 
numerical  capability  for  DoD  software  systems. 

Improvements  and  Enhancements 

Every  popular  piece  of  software  goes  through 
revisions  based  on  the  evaluations  and  needs  voiced  by  its 
users.  If  this  math  unit  becomes  popular  enough  to 
warrant  revisions,  the  most  useful  will  probably  be  either 
to  improve  MATHPAK's  efficiency  or  to  break  the  unit  up 
into  smaller  packages. 

Working  to  improve  the  efficiency  of  a  piece  of 
software  is  a  very  common  revision.  Work  in  this  area 
would  surely  be  able  to  increase  MATHPAK's  execution 
speed.  But  spending  a  lot  of  time  on  such  work  for 
IMPLMENT  is  not  recommended,  since  the  implementation 
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independent  version  designed  in  this  project  is  not 
intended  to  produce  the  best  efficiency.  An 
implementation  really  concerned  with  iMPLMENT's  efficiency 
can  write  its  own  tailored  version. 

It  is  also  possible  that  users  could  become  concerned 
with  the  size  of  MATHPAK,  particularly  when  many  users 
will  surely  not  need  all  of  the  functions  included  in 
MATHPAK.  Future  work  could  break  up  MATHPAK's  various 
groups  of  functions  (see  Appendix  A)  into  separate 
packages.  In  this  way  a  user,  or  a  software  system,  need 
only  integrate  into  its  library  the  packages  needed  for 
the  application  at  hand. 

If  users  begin  to  recognize  the  math  unit  as  a 
valuable  tool  in  a  language  environment,  they  will  also 
surely  ask  for  more.  They  will  want  MATHPAK  to  be  able  to 
provide  every  conceivable  math  function.  This  could 
include,  but  certainly  would  not  be  limited  to,  a  complete 
spectrum  of  operations  and  functions  for  use  on  complex 
numbers  and  matrices.  This  would  be  a  valuable 
enhancement  for  many  engineering  applications,  for 
example. 

The  future  for  both  Ada  and  the  math  unit  is 
promising.  This  writer  hopes  to  remain  involved  with  the 
development  of  both,  as  software  systems  become  more  and 
more  critical  to  the  mission  of  the  DoD. 


54 


1.  "A  Proposed  Standard  for  Binary  Floating-Point 
Arithmetic,"  Computer .  1A:  51-62  (March  1981). 

2.  Appl e  u.  Monitors  Pee] ed .  Cupertino,  California: 

Apple  Computer  Inc.,  1981. 

3.  Association  of  Computing  Machinery.  r<->l  1  ected  ACM 
Algorithms.  New  York:  Association  of  Computing 
Machinery,  1976. 

4.  Beathmaxh  Bapcxs  in  Electrical  Engineering  and 
Computer  Science/21 :  Computer  Arithmetic,  Part  VI: 
Elementary  Functions,  edited  by  Earl  E.  Swartzlander , 
Jr.  Stroudsburg,  Pennsylvania:  Dowden,  Hutchinson  & 
Ross,  Inc.,  1980. 

5.  Brender,  R.  F.  and  I.  R.  Nassi.  "What  Is  Ada?" 
Computer.  11:  17-24  (June  1981)  . 

6.  Carlson,  W.  E.  "Ada:  A  Promising  Beginning," 

Computer .  1A:  13-15  (June  1981). 

7.  Casseres,  D.  "Bits  and  Bytes  in  Pascal,"  Byte ,  £: 
448-457  (October  1981) . 

8.  Clenshaw  C.  W. ,  G.  F.  Miller,  and  M.  Woodger, 
"Algorithms  for  Special  Functions  I,"  Numeri schp 
Mathematik .  A:  403-419  (1963)  . 

9.  Cody,  W.  J.  "Analysis  of  Proposals  for  the 
Floating-Point  Standard."  Computer .  1A:  63-68  (March 
1981)  . 

10.  Cody,  W.  j.  and  W.  Waite.  &af, ,f.wa,r.e  Manual  fox,  the 
Elementary  Functions .  Englewood  Cliffs,  N.  J. : 
Prentice-Hall,  Inc.,  1980. 

11.  Coonen,  J.  T.  "An  Implementation  Guide  to  a  Proposed 
Standard  for  Floating-Point  Arithmetic,"  Computer , 

11:  68-79  (January  1980). 

12.  £££  Standard  Mathematical  Xafalea  (Twenty-fifth 
Edition),  edited  by  William  H.  Beyer,  Ph.D.  Boca 
Raton,  Florida:  CRC  Press,  Inc.,  1980. 


13.  Department  of  Defense.  Reference  Manual  for  the  Ada 
Programming  Language .  Proposed  Standard  Document. 
Arlington,  Virginia:  Defense  Advanced  Research 
Projects  Agency,  July  1980.  (AD  A090  709) 


14.  - .  Requi  ^mpnl-s  for  Ada  Programming  Support 

Environments ;  STQNEMAN.  Washington,  D.  C.:  Department 
of  Defense,  February  1980.  (AD  A100  404) 

15.  - .  Requirements  far.  High  Order  Computer 

Programming  Languages :  STEELMAN.  Washington,  D.  C. : 
Department  of  Defense,  June  1978.  (AD  A059  444) 


16.  Espinosa,  C.  Appl e  XL  Reference  Manual .  Cupertino, 
California:  Apple  Computer  Inc.,  1981. 

17.  Evans,  a.  A  Comparison  of  Programming  Languages;  Ada, 
Praxis .  Pascal .  £,  prepared  for  Lawrence  Livermore 
National  Laboratory.  Cambridge,  Massachusetts:  Bolt 
Beranek  and  Newman  Inc.,  April  1981. 

18.  Fisher,  D.  A.  "DoD's  Common  Programming  Language 
Effort,"  Computer .  H:  24-33  (March  1978). 

19.  Garlington,  A.  R.  Preliminary  Design  and 
Implementation  of  an  Ada  Pseudo-Machine.  MS  Thesis. 
Wright-Patterson  AFB,  Ohio:  Air  Force  Institute  of 
Technology,  March  1981.  (AD  A100  796) 

20.  Goodenough,  J.  B.  "The  Ada  Compiler  Validation 
Capability,"  Computer .  14:  57-64  (June  1981). 

21.  Hart,  J.  F.  and  others.  Computer  Approximations. 
Huntington,  New  York:  Robert  E.  Krieger  Publishing 
Company,  1978. 

22.  Honeywell,  Inc.,  Cii  Honeywell  Bull,  and  Inria. 

Formal  Definition  oL  the  Ada  Programming  Language. 
Arlington,  Virginia:  Defense  Advanced  Research 
Projects  Agency,  November  1980. 

23.  Hough,  D.  "Applications  of  the  Proposed  IEEE  754 
Standard  for  Floating-Point  Arithmetic,"  Computer , 

14.:  70-74  (March  1981)  . 

24.  Ichbiah,  J.  D.  and  others.  "Rationale  for  the  Design 
of  the  Ada  Programming  Language,"  ACM  STGPT.AN 
Notices  r  14:  No.  6  Part  B  (June  1979) . 

25.  Kahan,  W.  Xmplpjnentati  on  of.  Algorithms.  Washington, 

D.  C.:  Office  of  Naval  Research,  1973.  (AD  769  124) 

26.  Kernighan,  B.  W.  and  p.  J.  Plauger.  Software  Tools  la 
Pascal .  Reading,  Massachusetts:  Addison-Wesley 
Publishing  Company,  1981. 

27.  Knuth,  D.  E.  XL&  Act  of.  Computer  Programming ,  Volume 
1:  Fundamental  Algor i t hms  (Second  Edition) .  Reading, 


56 


Massachusetts:  Addison-Wesley  Publishing  Company, 
1973. 


28.  - .  The  Art  of  Computer  Programming,  Volume  2: 

Seminumer ical  Algorithms .  Reading,  Massachusetts: 
Addison-Wesley  Publishing  Company,  1971. 

29.  Loveman,  D.  B.  "Ada:  How  Big  a  Difference  Will  It 
Make  in  Software?"  Military  Electronics/ 
Countermeasures ,  1:  74-84  (May  1981) . 

30.  Miller,  G.  F.  "Algorithms  for  Special  Functions  II," 
Numerische  Mathematik.  2:  194-196  (1965). 

31.  Osborne,  A.  and  J.  Kane.  An  introduction 
Microcomputers ,  Volume  2:  Some  Real  MiCXOPr OCfiS-SOXS . 
Berkeley,  California:  Osborne  &  Associates,  Inc., 
1978. 

32.  Raskin,  J.  "Unlimited  Precision  Division,"  Byte.,  A: 
154-156  (February  1979). 

33.  Softech,  Inc.  Ada  fnmpi i er  Validation  Implement ers  ? 
Guide.  Arlington,  Virginia:  Defense  Advanced  Research 
Projects  Agency,  October  1980.  (AD  A091  760) 

34.  Softech,  Inc.  Evaluation  of  Algol  ££,  Jovial  13E, 
Pascal .  Simula  £2,  and  lacpol  versus  TINMAN 
Requirements  for  a  Common  High  Order  Programming 
Language.  Waltham,  Massachusetts:  Softech,  Inc., 
October  1976.  (AD  A037  637) 

35.  Stenning,  V.  and  others.  "The  Ada  Environment:  A 
Perspective,"  Computer .  11:  26-36  (June  1981). 

36.  Tiberghien,  J.  The  Pascal  Handbook .  Berkeley, 
California:  Sybex,  Inc.,  1981. 

37.  Whitaker,  W.  A.  "Comments  on  Portions  of  the  ACM 
SIGPLAN  on  the  Ada  Programming  Language  Not  Available 
in  the  Proceedings,"  Ada  Implementor  1 s  Newsletter ♦ 
October,  January,  February,  1981. 

38.  Wolfe,  M.  I.  and  others.  "The  Ada  Language  System," 
Computer .  14 :  37-45  (June  1981) . 

39.  Wynn,  P.  "An  Arsenal  of  Algol  Procedures  for  Complex 
Arithmetic,"  EH,  2:  232-255  (1962). 


57 


APPENDIX  A 


MATHPAK  Structure 


Support  Routines 

INITMASKS 

POPARG 

PUSHARG 

WRITEVAL 

WRITEBIT 

GETSTATZERO 

GETNEWSIZE 

CHKHIWORDEND 

CHKLOWORDEND 

SHIFTRIGHT 

SHIFTLEFT 

BITVALFILL 

INTBITREP 

RELBITREP 

COMPLMENT 

ABSVALINT 

SETWORDS 

EXPOSIZE 

CHECKEXPO 

SAMEI NTPREC I S I ON 

S AMERELPREC I S I  ON 

ADDARGS 

BITSTOBITS 

FINDNONOBIT 

FIND1STFRACBIT 

SETSIGBITS 

COPYEXPO 

POWEROF 

CALCEXPO 

INTDECREASE  (I) 

RELDECREASE  (I) 


Main  Functions 

Representation 

FLOAT 

RELTOINT  (I) 
INTSIZECHANGE 
RELSIZECHANGE 
ABSVALI  (I) 
ABSVALR  (I) 

Arithmetic 

PLUSH 
PLUSRR 
PLUSIR 
PLUSRI 
PLUSI 
PLUSR 
MINUSII 
MINUSRR 
MINUSIR 
MINUSRI 
MINUS I 
MINUSR 
MULTI I  (I) 
MULTRR  (I) 
MULTIR  (I) 
MULTRI  (I) 
DIVII  (I) 
DIVRR  (I) 
DIVIR  (I) 
DIVRI  (I) 

REMI  (I) 

MODI  (I) 

Exp/Log 

POWERII  (I) 
POWERRR  (I) 
POWERIR  (I) 
POWERRI  (I) 
SQRTI  (I) 
SQRTR  (I) 

EXP I  (I) 

EXPR  (I) 

LOGI  (I) 
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LOGR  (I) 

LNI  (I) 

LNR  (I) 

Trig 

SINI  (I) 

SI NR  (I) 
COSI  (I) 
COSR  (I) 
TANI  (I) 
TANR  (I) 
ARCSINI  (I) 
ARCSINR  (I) 
ARCCOSI  (I) 
ARCCOSR  (I) 
ARCTANI  (I) 
ARCTANR  (I) 
SINHI  (I) 
SINHR  (I) 
COSHI  (I) 
COSHR  (I) 
TANHI  (I) 
TANHR  (I) 


(I)  indicates  an  incomplete  module 
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APPENDIX  B 


TMPTiMRNT  Structure 


Support  Ron  hi  nps 


Main  Functions 


I NT ADD 
RELADD 
INTMULT 
RELMULT 
INTDIV  ( 
RELDIV  ( 


WRKAREATOSTACK 

ZEROOUTEXP 

COMPLEMENT 

EXPTONUMBER 

DECEXP 

CARRYONMSB 

NORMLEFTSHIFT 

ADDNORMALIZE 

RELFRACADDPREP 

RELEXPADDPREP 

PUSHRESULT 

CHKINTADD 

CHKRELADD 

MASKINIT 


SIGNINTADD 

ADDGENERAL 

INTPREPADD 

CHKHIWRDEND 

CHKLOWRDEND 

RIGHTS HI FT 

LEFTSHIFT 

EXPFROMNUMBER 

EXPSIZE 

ARGTOWORKAREA 


(I) 

(I) 

I) 

I) 


(I)  indicates  an  incomplete  module 
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appendix  c 


MATHPAK  Listing 


i ****************************************************************************) 

(*************************************************•***************************) 
(**  **) 

(**  PACKAGE  MATHPAK  **) 

(**  **) 

( ************************************************************«*******»*******) 
/A***************************************************************************) 


PROCEDURE  MATHPAK  (FUNCCODE:  INTEGER;  VAR  STAKPTR,  ERRCODE:  INTEGER) ; 


(*  This  is  a  Pascal  Procedure  which  is  meant  to  correspond  to  an  Ada  Package. 
The  code  is  written  in  Pascal,  but  it  is  written  as  much  like  Ada  as  possible 
so  that  it  can  be  translated  into  Ada.  *) 

(*  This  Package  is  designed  to  receive  a  function  code  and  a  stack  pointer 
from  the  caller  during  execution.  The  function  code  tells  the  package  which 
function  to  perform,  and  the  stack  pointer  tells  the  package  where  on  the 
memory  stack  to  find  the  arguments  for  the  function.  The  package  "pops"  the 
arguments  from  the  stack,  performs  the  specified  function,  and  then  "pushes" 
the  result  back  on  the  memory  stack.  It  passes  back  the  stack  pointer 
pointing  to  the  result  and  an  error  code.  It  is  assumed  that  the  words  of 
each  argument  passed  to  MATHPAK  on  the  stack  run  from  the  most  significant 
portion  of  the  number  (top)  to  the  least  significant  (bottom).  MATHPAK 
puts  the  results  back  on  the  stack  in  the  same  manner.  *) 

(*  MATHPAK  permits  arguments  of  arbitrary  precision.  It  requires  the  top  word 
of  the  stack  to  contain  an  integer  representing  the  number  of  bits  of 
precision  of  (number  of  total  bits  used  by)  the  first  argument.  This  is 
followed  by  the  first  argument,  starting  with  the  most  significant  bit  of  the 
stack  word  and  using  contiguous  words  in  memory.  Then,  if  two  arguments 
are  necessary  for  the  desired  function,  the  next  word  contains  another  integer 
for  the  precision  of  the  second  argument,  followed  by  the  second  argument  in 
contiguous  words  of  memory.  MATHPAK  will  accept  any  integer  for  the  given 
precisions,  but  it  will  use  no  less  than  one  full  word  and  no  more  than  the 
maximum  number  of  words  allowed  by  its  implementation.  (Note:  if  an  argument 
is  real,  this  precision  includes  the  total  bits  of  the  sign,  exponent,  and 
fractional  part  of  the  number.)  It  will  also  round  any  precision  not  a 
multiple  of  machine  words  up  to  the  next  full  word  of  precision.  The  result 
will  be  returned  on  the  top  of  the  stack  in  the  highest  precision  of  the 
arguments  used  rounded  up  to  the  next  complete  machine  word.  *) 
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(*  One  exception  to  the  above  is  for  the  case  when  MATHPAK  is  called  for  the 
purpose  of  changing  the  precision  of  an  argument.  In  this  case,  the  first 
word  on  the  stack  must  contain  an  integer  representing  the  number  of  bits 
of  precision  desired  for  the  argument.  The  second  word  must  then  contain 
the  present  precision  of  the  argument,  and  then  this  is  followed  by  the 
argument,  using  contiguous  words  in  the  stack.  The  result  is  returned  in 
the  desired  precision  on  the  top  of  the  stack.  *) 

(*  The  calling  routine  can  either  keep  track  of  the  precision  it  expects  the 

MATHPAK  result  to  have  or  else  it  can  keep  track  of  the  stack  position  where 

it  began  to  load  information  for  the  call  to  MATHPAK.  In  the  latter  case, 
both  the  starting  and  ending  locations  of  the  result  on  the  stack  are  known, 
so  the  precision  can  be  easily  calculated.  *) 

(*  The  number  representations  used  by  the  MATHPAK  are  as  follows: 

Integers  are  in  2's  complement  form. 

Floating  point  (real)  numbers  have  a  sign  bit,  followed  by  the  exponent, 
followed  by  the  fractional  part.  The  exponent  uses  the  smallest  number  of 
bits  which  can  hold  an  exponent  equal  to  from  +4  to  -4  times  the  length  of 

the  fractional  part  in  bits.  The  exponent  is  biased  by  one  less  than  2  to 

the  power  of  one  less  than  the  number  of  bits  in  the  exponent.  This  bias 
means  that  the  value  stored  in  the  exponent  is  never  negative,  so  the  exponent 
aoes  not  need  a  sign.  The  fractional  part  of  the  real  number  always  has  a 
positive  representation  and  the  binary  point  is  always  assumed  to  be  in 
front  of  (to  the  left  of)  the  first  fractional  bit.  A  non-zero  normalized 
real  number  will  always  have  a  1  in  the  first  (left-most)  fractional  bit.  *) 

(*  In  order  for  calling  programs  to  be  able  to  use  MATHPAK,  numbers  must  be 
passed  to  it  in  the  expected  representations.  It  is  usually  the 
responsibility  of  the  input/output  routines  of  the  language,  which  translate 
to  and  from  numerical  characters  and  words  of  the  given  numerical  type 
representing  the  proper  numerical  value,  to  use  the  proper  representations 
for  the  given  machine.  When  using  MATHPAK,  an  implementation  will  probably 
want  to  provide  modified  input/output  routines  v/hich  will  work  with  the 
proper  MATHPAK  representations.  These  routines  can  use  MATHPAK 's 
representation  functions,  as  necessary,  to  help  to  accomplish  this.  *) 

(*  In  order  to  use  the  MATHPAK,  another  package,  called  IMPLMENT,  is  also 
required.  This  package  is  completely  independent  of  the  MATHPAK,  but  it 
contains  routines  which  complete  the  jobs  started  by  many  of  the  MATHPAK 
functions.  IMPUMENT  contains  routines  which  can  be  tailored  to  a  specific 
machine  implementation,  if  desired.  The  IMPLMENT  provided  with  the  MATHPAK 
is  one  which  works  for  the  APPLE  II,  but  when  completed  it  should  be 
inplementation  independent.  However,  no  claim  is  made  that  it  is  the  most 
efficient  package  for  any  implementation.  *) 
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(*  MATHPAK' s  code  is  designed  to  be  entirely  inplenentation  independent. 

This  is  accomplished  through  the  use  of  the  declared  constants.  When 
implementing  MATHPAK,  before  compiling  it  the  constants  must  be  set  to  the 
proper  values  for  the  environment.  And  that’s  all.  It  should  then  work 
properly  for  any  implementation,  provided  the  conventions  established  by 
the  implementation  (through  setting  the  constants)  are  adhered  to  and  the 
proper  interfacing  (with  calling  parameters  and  number  representations)  is 
done.  *) 

(*  The  stackpointer  used  by  the  MATHPAK  is  an  index  into  an  integer  array 
representing  the  memory  stack.  The  calling  program  must  declare  this  array 
and  call  it  "S".  The  stack  is  assumed  to  run  from  a  higher  memory  location 
(bottom)  to  a  lower  memory  location  (top) .  The  constant  values  for  UPSTACK 
and  DCMJSTACK  must  be  reversed  if  calling  routines  are  expected  to  build  the 
stack  in  the  reverse  nanner.  *) 

(*  Word  bits  are  indexed  assuming  the  most  significant  bit  is  the  largest 
numbered  bit  and  the  least  significant  bit  is  the  smallest  numbered  bit. 

The  constant  values  for  KORESIGBIT  and  LESSSIGQIT  must  be  reversed  if  using 
this  on  a  computer  which  indexes  bits  in  the  reverse  manner.  *) 

(*  In  the  development  of  this  MATHPAK,  the  intention  has  been  to  use  ISO 
Standard  Pascal  throughout.  However,  the  development  was  done  on  an  APPLE  II, 
which  uses  UCSD  Pascal.  No  guarantee  can  be  made  that  no  non-standard  Pascal 
exists  here  nor  that  this  MATHPAK  will  work  on  every  Pascal  compiler  as  written. 
In  fact,  it  is  probable  that  some  of  the  bit  manipulations  will  not  work 
properly  in  Standard  Pascal  in  their  present  form.  Although  seme  masking  has 
been  introduced  in  this  version,  it  is  not  necessarily  complete,  and  packing 
and  unpacking  of  packed  bit  arrays  have  not  even  been  addressed.  Since 
UCSD  Pascal  does  automatic  packing  and  unpacking,  these  issues  are  of  no 
concern  for  an  AFPLE  implementation.  However,  they  make  a  difference  in 
Standard  Pascal.  *) 

(*  The  MATHPAK  is  presently  incomplete.  Every  possible  attempt  has  been 
made  to  make  the  documentation  reflect  the  current  status  and  be  accurate 
and  complete  for  that  status.  *) 
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( **************************************************************************** ) 


OCKST 

WORDSIZE  -  16; 
MSBITNO  ■  15; 

LSBITND  =  0; 

XTRABIT  -  16; 

MINBIT  »  -I; 

UPSTACK  =  -1; 

DCWNSTACK  =  1; 

MORESIGBIT  *  1; 

LESSSIGBIT  =  -1; 

MAXW3RDSFORARG  a  16; 
XTRAWORD  *  17; 


(*  Constants  must  be  set  to  correspond  to  the  *) 
(*  environment  *) 

{*  Number  of  bits  in  a  machine  word  used  to  *) 
(*  perform  integer  operations  *) 

(*  The  number  of  the  most  significant  bit  of  *) 
(*  an  integer  word  *) 

{*  The  number  of  the  least  significant  bit  of  *) 
(*  an  integer  word  *) 

One  more  than  the  largest  legal  bit  number  *) 
(*  of  an  integer  word  *) 

(*  One  less  than  the  smallest  legal  bit  number  *) 
(*  of  an  integer  word  *) 

(*  -1  if  stack  built  from  high  memory  (bottom)  *) 
(*  to  lw  memory  (top)  and  +1  if  stack  built  *) 
(*  opposite  way  *) 

(*  +1  if  stack  built  fran  high  memory  (bottom)  *) 
{*  to  low  memory  (top)  and  -1  if  stack  built  *) 
(*  opposit  way  *) 

(*  +1  if  bits  in  a  word  are  numbered  from  least*) 
(*  significant  (lowest  number)  to  most  signifi-*) 
(*  cant  (highest  number)  and  -1  if  bits  *) 

(*  numbered  opposite  way  *) 

(*  -1  if  bits  in  a  word  are  numbered  from  least*) 
(*  significant  (lowest  number)  to  most  signifi-*) 
(*  cant  (highest  number)  and  +1  if  bits  *) 

(*  numbered  opposite  way  *) 

(*  Largest  number  of  words  permitted  for  a  *) 
(*  numerical  argument  for  this  implementation  *) 
(*  One  more  than  MAXWORDSFORARG  *) 


ERRMESSAGE  =  ( NDERROR ,  OOHSTRAINTERROR ,  SIGNIFICANCEIDST ,  OVERFLCJ 1 ,  UNDERFLOW , 
DIVISIONBYZERO,STORAGEERHOR) ; 

MAXBITINDEX  =  MJNBIT . .  XTRABIT; 

MAXIORDINDEX  «  O..XTRAWORD; 

TRIREP  =  (A,B,C) ; 

BITINDEX  *  LSBITHD . . MSBITND ; 

VORDINDEX  *=  O..MAXVORDSFORARG; 

ARGINDEX  =  1..3; 

IOTARRAY  =  ARRAY [ARGINDEX, WQRDINDEX]  OF  INTEGER; 

BITARRAY  »  ARRAY  [ARGINDEX,WORDINDEX]  OF  PACKED  ARRAY  [BITINDEX]  OF  BOOLEAN; 
BOOLARRAY  =  ARRAY  [ARGIM3EX ,  WQRDINDEX]  OF  BOOLEAN; 

ARGUMENT  ■  RECORD  CASE  TRIREP  OF 

A:  (INT:  IOTARRAY);  (*  This  representation  lets  HATHPAK  *) 

B:  (BIT:  BITARRAY) ;  (*  interpret  a  word  any  way  it  wants.  *) 

C;  (BOOL:  BOOLARRAY);  (*  This  is  useful  for  bit  manipula-  *) 

END;  (*  tions.  *) 

MASK  IOTARRAY  =*  ARRAY  [BITINDEX]  OF  INTEGER; 

MASKBOOLARRAY  =  ARRAY [BITINDEX]  OF  BOOLEAN; 

MASK  =  RECORD  CASE  BOOLEAN  OF 
TRUE:  (INT:  fASKIOTARRAY)  ; 

FALSE:  (BOOL:  MASKBOOLARRAY) ; 

END; 


BIT1C, 

EXPBITND, 

FLOATOITOO, 

INTBirO:  MAXBITINDEX; 

SHIFT3ITS, 

BITCOUNT, 

iiotitcount, 

PRECISION, 

EXPOLENGTH, 

EXPCWORDBITS :  INTEGFK; 

WORDNO, 

WORDSUSED, 

MORDDIFF, 

WORDCOUMT:  WORDHOEX; 

EXH-JORDfD, 

INIWQRDNO, 

FUATWORDtD:  NAXWORDINDEX  ; 

ARGID:  ARGINDEX; 

COUNTER, 

IfOTASE, 

EXPO IAS, 

EXP:  INTEGER; 

ERR:  ERRMESSAGE; 

ARG:  ARGUMENT; 

LORDS:  ARRAY  [1..3]  OF  INTEGER; 
flASKARRAY:  MASK;  (*  Bit 


(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

<* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

masKs 


Indexes  for  bit 


argument  numbers 
General  counter  *) 

Variables  for 

exponent 

calculations 

Error  message 
Working  area 

Number  of  words  in  each  ARG 
for  changing  bit  representations 


( a****************************#**********************************************) 


(****************************************************************************) 


(*  *) 

(*  SUPPORT  ROUTINES  *) 

(*  *) 


\ -  .  , 


PROCEDURE  INITMASKS;  {*  Initializes  the  array  of  mask  words  for  use  *) 

{*  by  the  routines  which  change  the  bit  values  *) 
(*  of  any  argument.  This  array  consists  of  one*) 
(*  word  for  each  bit  in  a  memory  word,  and  each*) 
(*  mask  word  contains  a  1  in  the  bit  number  *) 
(*  which  corresponds  to  the  word  number  in  the  *) 
(*  array.  All  other  bits  in  each  word  are  0.  *) 

(*  Uses  LSBITNO,  BITNO,  MSBITNO,  MASKARRAY,  *) 
(*  MORES IGB IT,  COUNTER,  WORDSIZE,  LESSSIGBIT.  *) 

BEGIN 

MASKARRAY.IOT[LSBITNO]  :*  1; 

BITNO  :=  LSBITNO  +  MORESIGBIT; 

FOR  COUNTER  :=  2  TO  VJORDSIZE  DO  BEGIN 

MASKARRAY. IOTIEITND]  :*  2  *  MASKARRAY.IOT[BITND+LESSSIGBIT) ; 

BITNO  :=  BITNO  +  MORESIGBIT; 

END;  (*  FOR  *) 

END;  (*  INITMASKS  *) 

(*•*•*•****) 


PROCEDURE  POPARG ( ARGNUM ;  ARG INDEX) ;  (*  Takes  an  argument  from  the  memory*) 

(*  stack  and  writes  it  into  the  *) 
(*  appropriate  ARG,  depending  on  the*) 
{*  value  of  ARGNUM.  Leaves  the  stack*) 
(*  pointer  pointing  to  the  next  word*) 
(*  after  the  argument  on  the  stack.  *) 
(*  Uses  VJORDNO,  WORDSUSED,  ARG,  S,  *) 
(*  STAKPTR,  DOWNSTACK.  *) 

BEGIN 

FOR  WORDNO  :«  1  TO  WORDSUSED  DO  BEGIN 

ARG.  INI’ (ARGNUM,  WORDNO]  :«  S (STAKPTR]; 

STAKPTR  :■  STAKPTR  +  DOWNSTAGE; 

END;  (*  FOR  *) 

END;  (*  POPARG  *) 

(****«*•***) 
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PROCEDURE  PUSHARG ( ARGNUH :  ARGINDEX) ; ( *  Moves  the  stack  pointer  to  the  *) 

(*  next  word  before  the  top  of  the  *j 
(*  stack  and  writes  the  appropriate  *) 
(*  argument  from  ARC,  depending  on  *) 
(*  the  value  of  ARGUUM,  onto  the  top*) 
(*  of  the  stack.  Leaves  the  stack  *) 
(*  pointer  pointing  to  the  new  top  *) 
(*  of  the  stack.  *) 

(*  Uses  STAKPTR,  WORDED,  WORDSUSED,  *) 
(*  S,  ARG,  UPSTAGE.  *) 

BEGIN 

FOR  HQRDNO  :*  TORDSUSED  DCHNXO  1  DO  BEGIN 

STAKPTR  :=  STAKPTR  +  UPSTAGE ; 

S( STAKPTR]  :=  ARG.IHT[ARGNUM,VDRDNO] ; 

E ND;  (*  FOR  *) 

El®;  (*  PUSHARG  *) 

(**********) 

PROCEDURE  WRITEVAL(BITVALUE:  (*  Writes  a  boolean  value  specified*) 

BOOLEAN;  ARGNORES:  ARGINDEX;  (*  by  the  parameter  BITVALUF  to  a  *) 

WORDNORES:  WORDINDEX;  {*  particular  bit  in  ARG  specified  *) 

BITNDRES:  BITINDEX) ;  (*  by  the  index  parameters  of  the  *) 

(*  call.  *) 

(*  Uses  ARG,  MASKARRAY.  *) 

BEGIN 

IF  (BITVALUE.  TRUE)  THEN 

ARG.BOOI  -AfsG  DRES,EDRDNORES]  :=  ARG . BOOL [ ARG ORES , NORDMDRES ]  OR 
MASKA^'V .  BOOL  [  BITNDRES  ] 

ELSE 

ARG .  BOOL  ( ARGI  ORES ,  WORDEDRES )  :=  ARG. BOOL  [ARGJDRES,UORDNOR£S]  At® 
NOT  MASKARRAY . BOOL [ BITNDRES ] ; 

END;  (*  WRITEVAL  *) 

(**********) 
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PROCEDURE  WRITEBIT(ARGtOSOURCE: 

(*  Writes  one  bit  value  from  one 

*) 

ARGINDEX;  WORDNOSOURCE:  WORDINDEX; 

(*  location  to  another  without 

*) 

BITNOSOURCE:  BITINDEX; ARGNORES: 

(*  altering  the  value  of  any 

*> 

ARGINDEX  ;WORDNORES:  WORDINDEX; 

(*  other  bits  in  the  word  being 

*) 

BITNORES:  BITINDEX); 

(*  written  to.  Both  the  source 

*) 

(*  and  result  bits  must  be 

*) 

(*  somewhere  in  ARG.  The  first 

*> 

(*  3  parameters  are  indexes  for 

*) 

(*  the  source  bit  and  the  last  3 

*) 

(*  are  indexes  for  the  result 

*) 

(*  bit. 

*) 

(*  Uses  ARG. 

*) 

(*  Calls  WRITEVAL. 

*) 

(*  Possible  BUGS  -  ARG  will  need 

*) 

(*  to  be  unpacked  or  masked  in 

*) 

(*  Standard  Pascal  to  load 

*) 

(*  BOOLVAL  properly. 

*) 

VAR 

BCOLVAL:  BOOLEAN; 

BEGIN 

BOOLVAL  :=  ARG.BIT[ARGI©SOURCE,WORDf£>SCURCErBnNOSOURCE] ; 

WRITEVAL  ( BOOLVAL ,  ARGNORES ,  VORDNORES ,  B I1NORES) ; 

END;  (*  WRITEBIT  *) 

(**********) 

FUNCTION  GETSTATZERO:  BOOLEAN;  (*  Looks  at  the  ARG  referenced  by  the  *) 

(*  present  value  of  ARGNO  and  checks  *) 
(*  one  by  one  to  see  if  each  word  of  ARG*) 
(*  has  a  value  of  zero.  Returns  TRUE  *) 
(*  if  all  words  of  ARG  are  zero  and  *) 
(*  FALSE  if  at  least  one  is  not.  *) 

(*  Uses  COUNTER,  WORDS,  ARGNO,  ARG.  *) 

BEGIN 

COUNTER  :=  1; 

WHILE  ((COUNTER  <=  WORDS [ARGNO] )  AND  (ARG. INTfARGND, COUNTER]  =  0))  DO 
COUNTER  ;=  COUNTER  +  1; 

IF  (COUNTER  >  WORDS  [ARGNO])  THEN 
GETSTATZERO  :=  TRUE 

ELSE 

GETSTATZERO  :=  FALSE; 

END;  (*  GETSTATZERO  *) 

(**♦*♦*****) 
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PROCEDURE  GETNEWSIZE; 


(*  Gets  the  value  of  the  number  of  bits  for  *) 
(*  the  new  size  of  the  argument  fran  the  top  *) 
(*  of  the  stack.  Sets  the  stack  pointer  for  *) 
(*  the  new  top  of  the  stack.  Sets  WORDS [2]  *) 
(*  equal  to  the  value  of  the  number  of  words  *) 


(*  required  to  hold  the  new  size  of  the  *) 
(*  argument.  *) 
(*  Uses  S,  STAKPTR,  WORDS,  WORDSIZE,  *) 
(*  DCWNSTACK.  *) 


VAR 

NEWSIZE:  INTEGER; 

BEGIN 

NEKSIZE  :=  S [STAKPTR]; 

STAKPTR  :=  STAKPTR  +  DCNNSTACK; 

WORDS [2]  :=  NEWSIZE  DIV  WORDSIZE; 

IF  ((NEWSIZE  MOD  WORDSIZE)  <>  0)  THEN 
WORDS (2J  :=  WORDS (2 J  +  1; 

END;  (*  GETNEWSIZE  *) 


(**********) 

PROCEDURE  CHKHIWORDEND (VAR  WORDNUM:  (*  Increments  the  value  of  the  bit  *) 

WORDINDEX;  VAR  BITNUM:  (*  index,  BITNUM,  to  the  next  more  *) 

MAXBITINDEX) ;  (*  significant  bit,  and  then  checks*) 

(*  to  see  if  its  value  is  past  a  *) 
(*  word  boundary.  If  so,  it  decre-*) 
(*  malts  the  v/ord  number,  WORDNUM,  *) 
(*  and  sets  BITNUM  back  to  the  *) 
(*  value  of  the  least  significant  *) 
(*  bit  of  a  word,  LSBITNO.  *) 

(*  Uses  MSBITNO,  LSBITNO,  *) 

(*  MORESIGBIT.  *) 

BEGIN 

BITNUM  :=  BITNUM  +  MORESIGBIT; 

IF  ( ( ( BITNUM  >  MSBITNO)  AND  (MORESIGBIT  =1))  OR  ((BITNUM  <  MSBITNO) 
AID  (MORESIGBIT  =  -1)))  THEN  BEGIN 
BITNUM  :=  LSBITNO; 

WORDNUM  WORDNUM  -  1; 

END;  (*  IF  *) 

END;  (*  CHKHIWORDEND  *) 

(********* 
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PROCEDURE  CHKLCWQRD3© (VAR  WORDNUM:  (*  Decrements  the  value  of  the  bit  *) 

MAXWQRDINDEX;  VAR  BITNUM:  (*  index,  BITNUM,  to  the  next  less  *) 

MAXBITINDEX ) ;  (*  significant  bit,  and  then  checks*) 

(*  to  see  if  its  value  is  past  a  *) 

(*  word  boundary.  If  so,  it  incre-*) 

(*  ments  the  word  number,  WORDNUM,  *) 

(*  and  sets  BITNUM  back  to  the  *) 

(*  value  of  the  most  significant  *) 

{*  bit  of  a  word,  MSBITNO.  *) 

(*  Uses  LSBIUJO,  MSBITNO,  *) 

(*  LESSSIGBIT.  *) 

BEGIN 

BITNUM  :=  BITNUM  +  LESSSIGBIT; 

IF  ( ( (BITNUM  <  LSBITNO)  AM)  (LESSSIGBIT  =  -1))  OR  ((BITNUM  >  LSBITNO) 
AND  (LESSSIGBIT  =1)))  THEN  BEGIN 
BITNUM  :=  MSBITNO; 

WORDNUM  :=  WORDNUM  +  1; 

EM);  (*  IF  *) 

END;  (*  CHKLOMORDEND  *) 

(*****★*★**) 

PROCEDURE  SHIFTRIGHT ( ARGNUM :  (*  Shifts  bits  in  the  ARG  specified  by  *) 


ARGINDEX;  OLEWQRD:  (*  ARGNUM.  Writes  the  bit  indexed  by  *) 
MAXWORDINDEX;  OLDBIT:  (*  OLDWQRD  and  OLDBIT  to  NEWWORD  and  *) 
MAXBITINDEX;  VAR  NEWWORD:  (*  NEKBIT.  OLDWORD  and  OLDBIT  must  *) 
MAXWORDINDEX;  VAR  NE13IT:  (*  begin  at  the  index  values  for  the  *) 


MAXBITINDEX) ;  (*  least  significant  bit  to  be  shifted,  *) 

(*  and  NEMO©  and  UEWBIT  begin  at  the  *) 
(*  index  values  for  the  least  signifi-  *) 
(*  cant  destination  bit.  Works  from  the*) 


(*  least  significant  bit  up  and  shifts  *) 
(*  the  number  of  bits  specified  by  *) 
(*  SHIFIBITS.  Changes  index  values  as  *) 
(*  it  goes,  and  returns  the  final  value  *) 
(*  of  NEMO©  and  NEWBIT.  *) 
(*  Uses  SHIFTBITS.  *) 
(*  Calls  WRITEBIT,  QIKK IWORDEND .  *) 


BEGIN 

WHILE  (SHIFTBITS  >  0)  DO  BEGIN 

WRITEBIT  ( ARGNUM ,  OUJWORD ,  OLDBIT ,  ARGNUM ,  NEWWORD ,  NEWBIT) ; 
SHIFTBITS  :=  SHIFTBITS  -  1; 

CHKHHO©3©(OI©WORD,  OLDBIT)  ; 

QIKHIWORD3©  (NEUVJORD,  NEWBIT) ; 

END;  (*  WHILE  *) 

Q©;  (*  SHIFTRIGHT  *) 

(****♦♦****) 
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PROCEDURE  SHIFTLEFT(ARGUJM:  (*  Shifts  bits  in  the  ARC  specified  by  *) 

ARGINDEX;  VAR  NEWNORD:  {*  ARGNUM.  Writes  the  bit  indexed  by  *) 

MAXWDRDINDEX;  VAR  NENBIT: (*  OLDWCRD  and  OLDBIT  to  NEWWORD  and  *) 

MAXBITINDEX ;  OLDWORD :  (*  NEWBIT.  OLDWORD  and  OLDBIT  must  begin  *) 

MAXWORDINDEX;  OLDBIT:  (*  at  the  index  value  for  the  most  signifi-*) 

MAXBITINDEX);  (*  cant  bit  to  be  shifted,  and  NEWWORD  and  *) 

(*  NEWBIT  begin  at  the  index  value  for  the  *) 
(*  most  significant  destination  bit.  Works*) 
(*  frati  the  most  significant  bit  down  and  *) 
(*  shifts  the  number  of  bits  specified  by  *) 
{*  SHIFTBITS.  Changes  index  values  as  it  *) 


{*  goes,  and  returns  the  final  value  of  *) 
(*  NEWWORD  and  NEWBIT.  *) 
(*  Uses  SHIFTBITS.  *) 
(*  Calls  WRITEBIT,  CHKLOWORDEND.  *) 


BEGIN 

WHILE  (SHIFTBITS  >  0)  DO  BEGIN 

WRITEBIT  ( ARGNUM ,  OLDWORD ,  OLDBIT ,  ARGNUM ,  NEWWORD ,  NEWBIT)  ; 
SHIFTBITS  :=  SHIFTBITS  -  1; 

CHKLOWORDEND  ( OLDWORD ,  OLDBIT)  ; 

CHKLOMQRDEND  ( NEWWORD ,  NEWBIT)  ; 

END;  (*  WHILE  *) 

END;  (*  SHIFTLEFT  *) 

(*««*******) 


PROCEDURE  BITVALFILL ( BOOLVAL :  BOOLEAN; (*  Fills  the  bits  of  the  ARG  *) 

ARGNUM:  ARGINDEX;  WORDNUM:  (*  indexed  by  ARGNUM  with  the  *) 

MAXWORDINDEX;  BITNUM:  MAXBITINDEX;  ( *  value  of  BOOLVAL  one  by  one  *) 

ENDWORD:  WORDINDEX;  ENDBIT:  (*  starting  with  the  bit  indexed  *) 

BITINDEX) ;  (*  by  WORDNUM  and  BITNUM  and  end-  *) 

(*  ing  with  the  bit  indexed  by  *) 

(*  ENDWORD  and  ENDBIT,  working  *) 

(*  from  more  to  less  significant  *) 

(*  bits.  *) 

(*  Uses  LESSSIGBIT.  *) 


(*  Calls  WRITEVAL,  CHKLCX  VORDEND .  *) 

BEGIN 

REPEAT 

WRITEVAL ( BOOLVAL , ARGNUM , WORDNUM,  BITNUM) ; 

CHKLCWORDEND  (WORDNUM ,  BITNUM) ; 

UNTIL  ({WORDNUM  >  ENDWORD)  OR  ((WORDNUM  =  ENDWORD)  AND  ( ( (BITNUM  < 
ENDBIT)  AID  (LESSSIGBIT  =  -1))  OR  ((BITNUM  >  ENDBIT)  AID 
(LESSSIGBIT  =  1)))))  ; 

END;  (*  BITVALFILL  *) 

(**********) 
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PROCEDURE  IOTBITREP  (ARGNUM:  ARGINDEX) ;  (*  Gets  the  word  containing  the  *) 

(*  precision  of  the  next  argument*) 


(*  from  the  top  of  the  stack.  *) 
(*  From  this  it  determines  how  *) 
(*  many  words  are  necessary  to  *) 
(*  hold  the  next  argument  as  well*) 
{*  as  hew  many  bits  it  will  need  *) 
(*  to  be  shifted  (if  any)  in  *) 
(*  order  for  the  argument  to  end  *) 
(*  on  a  word  boundary.  The  *) 
(*  argument  is  then  popped  from  *) 


(*  the  stack  into  the  appropriate*) 
(*  ARG  as  specified  by  ARGNUM  and*) 


(*  then  shifted,  if  necessary.  *) 
(*  When  bits  are  shifted,  the  *) 
(*  remaining  bits  are  filled  with*) 
(*  the  value  of  the  sign.  *) 
(*  Uses  WORDSUSED,  S,  STAKPTR,  *) 
(*  WORDSIZE,  SHIFTBITS,  WORDS,  *) 
(*  ARG1D,  LSBITNO,  aRG,  MSBITNO,  *) 
(*  DOWNSTAGE,  MORESIGBIT,  *) 
(*  LESSSIGBIT.  *) 
(*  Calls  SHIFTRIGHT,  POPARG,  *) 
(*  BITVALFILL.  *) 


(*  Possible  BUGS  -  ARG  will  need  *) 
(*  to  be  unpacked  or  masked  in  *) 
(*  Standard  Pascal  to  pass  the  *) 
(*  proper  value  to  BITVALFILL.  *) 

VAR 

WORDNEW:  NAXVJDRD INDEX; 

BITOLD,  BITNEW:  MAXBITINDEX; 

BEGIN 

ARGID  :=  ARGIUN; 

WORDSUSED  J=  S[STAKPTR]  DIV  TORDSIZE; 

SHIFTBITS  :=  S(STAKPTR]  MOD  TORDSIZE; 

STAKPTR  :=  STAKPTR  +  DCVJNSTACK ; 

IF  (SHIFTBITS  <>  0)  THEN  BEGIN 
tORDSUSED  :=  WORDSUSED  +  1; 

W0RDNE17  :=  WORDSUSED; 

BITNEW  ;=  LSBITND; 

IF  (iORESIGBIT  =«  1)  THEN 

BITOLD  :=  VORDSIZE  -  SHIFTBITS  +  LSBITNO 

ELSE 

BITOLD  ;=  MSBITNO  +  SHIFTBITS  -1; 

SHIFTBITS  :=  ((WORDSUSED  -  1)  *  WORDSIZE)  +  SHIFTBITS  -  1; 

POPARG (ARGNUM) ; 

SH I FTR IGHT  ( ARGON , WORDSUSED ,  BI TOID , tORDNEW ,  BITOEt'/)  ; 
aJKHIWORDEND(KORDNEW, BITNEW)  ; 

BITVALFILL (ARG . BIT [ARGNUM , 1 , MSBITNO] , ARGNUM, 1 , MSEITND+LESSSIGBIT, 
WORDNEW, BITNEVV) ; 

END  (*  IF  *) 

ELSE 

POPARG (ARGNUM) ; 
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WORDS [ARGNUM]  :=  WORDSUSED; 

END;  (*  IWIBITREP  *) 

(**********) 


PROCEDURE  RELBITREP (ARGNUM:  ARG INDEX) ;  (*  Gets  the  word  containing  the  *) 

(*  precision  of  the  next  argument  *) 
(*  from  the  top  of  the  stack.  *) 
(*  From  this  it  determines  how  *) 
(*  many  words  are  necessary  to  *) 
(*  hold  the  next  argument  as  well  *) 
(*  as  how  many  bits  must  be  added  *) 
(*  (if  any)  in  order  to  make  the  *) 
(*  argument  end  on  a  word  *) 
(*  boundary.  If  bits  must  be  *) 
(*  added,  it  reads  the  last  word  *) 
(*  of  the  argument  into  the  first  *) 
(*  word  of  ARG ( 3 ]  and  writes  *) 
(*  zeroes  on  any  of  the  added  *) 
(*  bits.  Then  it  writes  that  *) 
(*  last  word  back  to  the  stack  and*) 
(*  pops  the  argument  from  the  *) 
(*  stack  into  the  appropriate  ARG  *) 
(*  as  specified  by  ARGNUM.  *) 
(*  Uses  WORDSUSED,  S,  STAKFTR,  *) 
(*  WORDSIZE,  SHIFTBITS,  WORDS,  *) 
(*  ARGD,  ARG,  BITNO,  DONNSTACK,  *) 
(*  UPSTACK ,  LSBITNO,  COUNTER,  *) 
(*  MORES IGBIT .  *) 
(*  Calls  WRITEVAL,  POPARG.  *) 


BEGIN 

ARGIO  :=  ARGNUM; 

JvORDSUSED  :=  S[STAKPTR]  DIV  WORDSIZE; 

SHIFTBITS  :=  S(STAKPTR)  MOD  WORDSIZE; 

STAKFTR  :=  STAKPTR  +  DCMJSTACK; 

IF  (SHIFTBITS  <>  0)  THEN  BEGIN 
WORDSUSED  ;=  WORDSUSED  +  1; 

ARG.INT[3,1]  :=  S(STAKFTRWORDSUSED*DOWNSTACK-KJPSrACK] ; 
BITNO  ;=  LSBITNO; 

FOR  COUNTER  :=  1  TO  (WORDSIZE-SHIFTBITS+LSBITNO)  DO  BEGIN 
WRITEVAL ( FALSE ,3,1, BITNO) ; 

BITNO  :=  BITNO  +  MORESIGBIT; 

END;  (*  FOR  *) 

S (STAKPTR WORDSUSED*DOWNSTACK+UPSr/CK]  ;=  ARG.INT[3,1] ; 
END;  (*  IF  *) 

WORDS [ARGNUM]  :=  WORDSUSED; 

POPARG  (ARGNUI-1)  ; 

END;  (*  RELBITREP  *) 

(******★*♦*) 
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PROCEDURE  CQHPLli£NT(  ARGNUM:  (*  Complements  an  integer  argument  in  ARC.*) 

ARGINDEX;  NUMTORDS:  (*  Does  not  change  a  zero  argument.  *) 

WORDINDEX) ;  (*  Uses  ARG,  TORDNO.  *) 

VAR 

CHANGEWDRD:  WORDINDEX; 

BEGIN 

CHANGEWQRD  :=  NUMTORDS; 

WHILE((ARG.IOT[ARGNUM,CHANGEWORD]  =  0)  AND  (CHANGEWDRD  <>  1))  DO 
CHANGEWDRD  :=  CHANGEWDRD  -  1; 

IF  (ARG.  INT(ARGNUM,CHAMGEWORD]  <>  0)  THEN  BEGIN 
FOR  TORDNO  :=  CHANGEWDRD  DCWNTO  1  DO 

ARG . BOOL [ ARGNUM , TORDNO ]  :=  NOT  ARG. BOOL  [ARGTUM,WORDNO] ; 
ARG.IMT[AKGHUM,CHANGEWQRDJ  :=  ARG .  INT  [ ARGfiUM , CHANGEWDRD]  +  1; 

END;  (*  IF  *) 

END;  (*  COMPLMENT  *) 

(★**★******) 

PROCEDURE  ABSVALINT ( ARGJ  JUM :  (*  Takes  any  integer  argument  from  ARG  and*) 


ARGINDEX;  NUMTORDS:  (*  turns  it  into  the  absolute  value  of  *) 

WORDINDEX) ;  {*  that  argument.  *) 

(*  Uses  ARG.  *) 

{*  Calls  COMPLMENT.  *) 

BEGIN 

IF  (ARG.  INT  [  ARGNUM,  1J  <  0)  THEN 
COMPmENT (ARGNUM, NUMTORDS)  ; 

END;  (*  ABSVALINT  *) 


(**********) 


PROCEDURE  SETTORDS;  (*  Assumes  that  the  number  of  words  used  by  *) 

(*  arguments  1  and  2  in  ARG  are  not  the  *) 
(*  same.  Sets  ARGNO  equal  to  the  number  of  *) 
(*  the  argument  which  needs  to  have  words  *) 
(*  added  (to  make  argument  sizes  the  same).  *) 
(*  It  also  makes  sure  that  WORDSUSED  con-  *) 
(*  tains  the  value  of  the  argument  using  the*) 
(*  most  words.  *) 
(*  Uses  WORDDIFF,  TOR DS,  ARGNO,  TORDSUSED,  *) 
(*  ARG.  *) 
(*  Calls  ABSVALINT.  *) 


BEGIN 

ARG.INT[3,1]  :=  VTORDS[1J  -  TORDS[2) ; 
ABSVALINT (3,1)  ; 

WORDDIFF  :=  ARG. 11/1(3,1] ; 

IF  (WORDS (1]  >  WORDS [2] )  THEN 
ARGND  :=  2 
ELSE  BEGIN 

ARGND  :=  1; 

TORDSUSED  :=  WORDS [2 ] ; 

END;  (*  ELSE  *) 

END;  (*  SETTORDS  *) 
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(*★**★★*★★*) 


FXJNCTICtJ  EXPOSIZE (MJMOFWORDS :  (*  Calculates  the  proper  sized  exponent  *) 
INTEGER):  INTEGER;  (*  for  a  real  argument  from  the  number  *) 

(*  of  words  in  the  argument  given  as  the*) 
(*  calling  parameter.  It  assumes  that  *) 
(*  the  smallest  possible  word  size  is  8  *) 


{*  bits.  It  uses  an  algorithm  which  *) 
{*  determines  the  smallest  exponent  *) 
(*  length  which  can  hold  an  exponent  *) 
(*  equal  to  from  +4  to  -4  times  the  *) 


(*  length  of  the  fractional  part  of  the  *) 
(*  real  number  in  bits.  It  returns  the  *) 
{*  number  of  bits  in  the  length  of  this  *) 
(*  smallest  exponent  as  the  value  of  the*) 
(*  function.  *) 

(*  Uses  PRECISION,  WORDSIZE.  *) 

VAR 

TRIALEXPO,  TRIALFRAC , TOIALPRECISION :  INTEGER; 

BEGIN 

PRECISION  :=  NUf-DFWORDS  *  WORDSIZE; 

TRIALEXPO  :=  5; 

TRIALFRAC  :=  4; 

TRIALPRECI S IOf I  :=  TRIALEXPO  +  TRIALFRAC  +  1; 

WHILE  (TRIALPRECISION  <  PRECISION)  DO  BEGIN 
TRIALEXPO  :=  TRIALEXPO  +  1; 

TRIALFRAC  TRIALFRAC  *  2; 

TRIALPRECISION  :=  TRIALEXPO  +  TRIALFRAC  +  1; 

END;  (*  WHILE  *) 

EXPOSIZE  :=  TRIALEXPO; 

END;  {*  EXPOSIZE  *) 


(****★***♦*) 
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PROCEDURE  CHECK EXPO;  (*  Checks  the  size  of  the  old  exponent  in  an  *) 

(*  argument  in  ARC  specified  by  ARGNO  *) 
(*  against  the  size  of  the  exponent  required  *) 
{*  by  an  argument  with  the  number  of  words  *) 
(*  specified  in  WORDSUSED.  if  the  exponent  *) 
(*  lengths  are  not  the  same,  the  one  *) 
(*  determined  from  WORDSUSED  is  assumed  to  be*) 
(*  larger,  and  the  argument  in  ARC  gets  its  *) 
{*  exponent  increased  by  the  number  of  bits  *) 
(*  necessary  to  rrake  it  equal  to  that  *) 
(*  determined  by  WORDSUSED.  The  argument  in  *) 
(*  ARC  is  now  assumed  to  use  the  number  of  *) 
(*  words  specified  in  WORDSUSED  and  all  its  *) 
(*  bits  except  the  sign  bit  and  the  first  *) 
(*  bit  of  the  exponent  are  shifted  to  the  *) 
(*  right  by  the  same  number  of  bits  which  *) 
{*  were  added  to  the  exponent.  The  bits  *) 
(*  added  to  the  exponent  are  the  opposite  *) 
(*  value  of  the  first  bit  of  the  exponent.  *) 
(*  This  serves  to  adjust  the  bias  for  the  *) 
(*  new  exponent  size.  *) 
(*  Uses  WORDS,  ARGNO,  WORDSUSED,  SHIFTBITS,  *) 
{*  MSBITNO,  LSBITNO,  MORDSIZE,  ARG,  *) 
(*  MORES IG3IT,  LESSSIGBIT.  *) 
(*  Calls  EXPOSIZE,  SHIFTRIGHT,  BITVALFILL.  *) 
(*  Possible  BUGS  -  ARG  will  need  to  be  un-  *) 
(*  packed  or  masked  in  Standard  Pascal  to  get*) 
(*  the  proper  value  for  OPPBIT.  *) 


VAR 

WQRDOLD,  WORDNEW:  MAXWORDINDEX; 

BITOLD,  BITNEW, 

OLDEXPOSIZE,NEWEXPOSIZE:  INTEGER; 

' OPPBIT j  BOOLEAN; 

BEGIN 

OLDEXPOSIZE  :=  EXPOSIZE (WORDS [ARGNO] )  ; 

NEWEXPOSIZE  :=  EXPOSIZE (WORDSUSED) ; 

SHIFTBITS  :=  VX3RDS(AR3IO]  *  WORDSIZE  -  2; 

WORDOLD  :=  WORDS [ARGNO] ; 

WORDS [ARGtOJ  :=  VJORDSUSED; 

IF  ( (NHVEXPOSIZE-OLDEXPOSIZE)  >  0)  THEN  BEGIN 
BITOLD  :=  LSBITID; 

V»RDtrti;  :=  WORDOLD  +  ((OLDEXPOSIZE  -  NEWEXPOSIZE)  DIV  WORDSIZE)  +  1; 
BITNEl'/  :=  MSBITNO  +  ( ( (OLDEXPOSIZE  -  NTJv’EXPOSIZE)  i»D  VJORDSIZE) 

*  LESSSIGBIT)  +  MORESIGBIT; 

IF  ( ( (BITNEW  >  MSBITNO)  AND  (MORESIGBIT  =1))  OR  ( (BITNEW  < 

NSBITNO)  AID  (MORESIGBIT  =  -1)))  THEN  BEGIN 
BITNEW  :=  LSBITNO; 

WORDNEW  :=  VJORDNEW  -  1; 

ED;  (*  IF  *) 

SHIFTRIGHT ( ARGID , WORDOLD ,  BITOLD , WORDNEW,  BITNEW) ; 

OPPEIT  :=  IUT  ARG.BIT[ARGJD,l,iISBI,nJCH-LESSSIGBITJ ; 

BITVALF I LL  ( OPPBIT ,  ARGtD ,  1 ,  MSBITNO+2  *LES  SSIGBIT ,  VDRDNEW ,  3ITNEW)  ; 

EID;  (*  IF  *) 
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END;  {*  CHECKEXPO  *) 


(★***★*****) 

PROCEDURE  SAHEII 7TPRECI S  ION ;  (*  Checks  to  see  if  the  two  arguments  in  *) 

(*  ARC  have  the  same  precision.  If  not  *) 
(*  it  takes  the  one  v/ith  least  precision  *) 
(*  and  expands  it  to  one  with  precision  *) 
(*  equal  to  the  other.  It  does  this  by  *) 
(*  moving  all  words  down  the  appropriate  *) 
(*  number  of  words  and  then  filling  the  *) 


(*  words  added  in  front  with  bits  with  *) 
(*  the  same  value  as  the  sign  of  the  *) 
(*  argument.  It  also  makes  sure  that  *) 
(*  WORDSUSED  ends  up  with  the  right  *) 
(*  value.  *) 
(*  uses  'WORDSUSED,  WORDS,  TORDID,  *) 
{*  WORDCOUNT,  ARC,  ARGO,  WORDDIFF,  *) 
(*  LSBITID,  MSBITND,  LESSSIGBIT.  *) 
(*  Calls  SETWORDS,  BITVALFILL.  *) 


(*  Possible  BUGS  -  ARG  will  need  to  be  *) 
(*  unpacked  or  masked  in  Standard  Pascal  *) 
(*  to  pass  the  proper  value  to  BITVALFILL*) 

3BGIN 

WORDSUSED  8*  WORDS [1]; 

IF  (WORDS [1]  <>  WORDS [2])  THEN  BEGIN 
SETWORDS; 

WORDID  :=  WORDSUSED; 

FOR  WORDCOUNT  :=  1  TO  WORDS  (ARGID]  DO  BEGIN 

ARG . INT  [ARGID , WORD’ D J  :=  /J^.i:JT[ARGID,VDRD:D-NORDDIFF]  ; 
VJORDIiO  :=  WORDID  -  1; 

END;  (*  FOR  *) 

BITVALFILL  (ARG .  BIT  [ARGID ,  1 ,  MSBITNO]  ,  ARGID  ,1,1  ISBITNCH-LESSSIGBIT, 
WORDDIFF, LSBITID) ; 

END;  (*  IF  *) 

END;  (*  SA'IEINTPRECISION  *) 


{***★****★*) 
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PROCEDURE  SAMERELPRECI S ION ;  {*  Cliecks  to  see  if  the  two  arguments  in  *) 

(*  ARC  have  the  same  precision.  If  not  *) 

(*  it  takes  the  one  with  least  precision  *) 

(*  and  expands  it  to  one  with  the  same  *) 

(*  precision  as  the  other.  It  does  this  by*) 

(*  adding  the  appropriate  number  of  words  *) 

{*  of  zero  to  the  end  of  the  argument.  It  *) 

(*  then  checks  the  length  of  the  exponent  *) 

(*  against  the  length  it  should  have  for  *) 

(*  the  new  precision.  If  the  exponent  *) 

(*  needs  to  be  lengthened  it  does  this  by  *) 

(*  adding  the  appropriate  bits  to  the  front*) 

(*  of  the  exponent  and  shifting  the  re-  *) 

(*  maining  bits  of  the  exponent  and  the  *) 

(*  bits  of  the  fractional  part  the  appro-  *) 

(*  riate  number  of  bits  to  the  right.  It  *) 

(*  also  makes  sure  that  WORDSUSED  and  *) 

(*  EXPOLfMGTH  end  up  with  the  right  value.  *) 

(*  Uses  WORDSUSED,  '.ORDS,  WRDNO,  ARGNO,  *) 

(*  ARC,  EXFOLEMGTH.  *) 

(*  Calls  SETWORDS,  CHECKEXPO,  EXPOSIZE.  *)  l 

BEGIN  • 

WORDSUSED  :=  WORDS [1];  ! 

IF  (WORDS[l]  <>  U0RDS[2])  THEM  BEGIN  ! 

SETWORDS; 

FOR  WORDNO  :=  ( WORDS  [ARG1D]  +1)  TO  VORDSUSED  DO 
ARG.INT[ARGID, NORDIC]  :=  0; 

CHECKEXPO; 

END;  (*  IF  *) 

EXPOLENGTH  :=  EXPOS  IZE  (WORDSUSED)  ; 

END;  (*  SAMERELPRECISION  *) 

(***★*♦****)  j 


\ 


i 
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PROCEDURE  ADDARGS  (*  Pushes  the  arguments  in  ARG[1]  and  ARG{2]  on  *) 

(ADDTYPE:  It/TEGER) ;  (*  the  stack  (along  with  a  word  specifying  the  *) 
(*  word  length  of  the  arguments)  and  calls  *) 

(*  IMPLMOJT  to  add  them  together.  Uses  the  *) 
(*  parameter  ADDTYPE  to  set  the  code  for  the  type*) 
(*  of  add  (integer,  real,  etc.)  to  pass  to  *) 

(*  IMPLEMENT.  Then  pops  the  result  from  the  stack*) 
(*  into  ARG[1] .  It  assumes  that  the  arguments  *) 
(*  each  occupy  the  number  of  words  specified  in  *) 
(*  WORDSUSED  and  that  both  arguments  are  *) 

(*  integers.  *) 

(*  Uses  STAKPTR,  S,  UDRDSUSED,  ERRCODE,  UPSTACK.  *) 
(*  Calls  PUSHARG,  Ii-IPUIENT,  POPARG.  *) 

BEGIN 

PUSHARG (1); 

PUSHARG (2) ; 

STAKPTR  :=  STAJCPTR  +  UPSTACK; 

S  (STAKPTR]  :=  VJORDSUSED; 

IMPLi  lENT  ( ADDTYPE ,  STAKPTR ,  ERRCODE)  ; 

POPARG(l) ; 

END;  (*  ADDARGS  *) 


(*♦*******♦) 


PROCEDURE  BITSTOBITS 

(NUMOFEITSs  INTEGER; 
FROMARGNO:  ARGINDEX ; 
FROMORDNO: 
MAXWORDINDEX ; 
FROiBITNO: 

MAXBITINDEX;  TOARGNO: 
ARGINDEX;  VAR 
TCWORDNO: 
MAXWORDINDEX ;  VAR 
TOBITNO;  MAXBITINDEX) 
BEGIN 


(*  Writes  bits  one  at  a  time,  in  order,  from  *) 
(*  most  to  least  significant,  from  one  *) 
(*  argument  in  ARG  to  another.  It  uses  the  *) 
(*  argument,  word,  and  bit  indexes  passed  as  *) 
(*  calling  parameters.  It  copies  the  number  *) 
(*  of  bits  specified  by  NUNOFBITS  and  does  *) 
(*  not  need  the  bits  copied  to  either  begin  *) 
(*  or  end  on  a  word  boundary.  Returns  the  *) 
(*  final  value  of  TCWORDIJO  and  TOBITNO.  *) 
(*  Uses  BITCOUOT.  *) 
(*  Calls  WRITEBIT,  CHKLCJ JORDEND .  *) 


FOR  BITCOUNT  :=  1  TO  NUI-DFBITS  DO  BEGIN 

WRITEBIT  ( FROHARGtX) ,  FROMl  K5RDND ,  FRQ IBITNO ,  TOARGTJO ,  TO170RDN0 ,  TOBITNO)  ; 
CHKIXMDRDEND  ( FROMWORDtD ,  FROMBITNO)  ; 

CHKLCHCRD END  (Ta SORDID ,  TOBITN3)  ; 

END;  (*  FOR  *) 

END;  (*  BITSTOBITS  *) 


(*****★«***) 
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PROCEDURE  FINDNONOBIT(ARGNUM:  {*  Finds  the  first  non-zero  bit  in  the  *) 
ARGIHDEX) ;  (*  appropriate  argument  in  ARG  specified  *) 

(*  by  ARGNUM,  starting  at  the  word  and  bit*) 
(*  indexed  by  ININORDNO  and  INTBITNO.  It  *) 
(*  goes  through  the  bits  from  most  to  *) 
{*  least  significant  until  a  1  is  found.  *) 
{*  IOTBITOOUNT  is  incremented  each  time  *) 
(*  the  indexes  are  incremented  for  a  new  *) 
(*  bit,  and  INTWORDNO  and  INTBITNO  retain  *) 


(*  pointing  to  the  "found"  bit  upon  *) 
(*  return.  *) 
(*  Uses  ARG,  INTWORDNO,  INTBITNO,  *) 
{*  INIBITCOUNT.  *) 
(*  Calls  CHKLOWORDE1JD.  *) 
{*  Possible  BUGS  -  ARG  will  need  to  be  *) 
(*  unpacked  or  masked  in  Standard  Pascal  *) 
(*  to  make  the  test  for  FALSE  work  *) 
(*  properly.  *) 


BEGIN 

WHILE  (ARG. BIT  [ARGNUM,  IlfTWORDNO,  INIBITt©]  =  FALSE)  DO  BEGIN 
CHKLOWORDEND  ( INTWORDtG ,  INTBIIIC)  ; 

INIBITCOUNT  :=  INTBITCOUNT  +  1; 

END;  (*  WHILE  *) 

END;  (*  FINDNONOBIT  *) 
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PROCEDURE  FIND1STFRACBIT;  (*  Finds  the  first  bit  of  the  fractional  part*) 

(*  of  a  real  number.  It  does  this  by  first  *) 
(*  determining  how  long  the  exponent  of  the  *) 
(*  number  is  and  then  comparing  this  with  the*) 


{*  wordsize  to  make  a  final  determination  of  *) 
(*  exactly  what  bit  of  what  word  in  the  *) 
(*  argument  is  the  first  fractional  bit.  It  *) 
(*  gets  the  size  of  the  argument  frcm  *) 
(*  WORDSUSED  and  leaves  the  word  and  bit  *) 
{*  indexes  for  the  "found"  bit  in  F1CATVJ0RDN0*) 
(*  and  FLOMBITNO  respectively.  *) 
(*  Uses  EXPOLENGTH,  FLCATTORDNO,  WORDSIZE,  *) 
(*  EXPCT70RDBITS,  FLOATBITNO,  WORDSUSED,  *) 
(*  HORESIGBIT,  LSBITNO,  LESSSIGBIT.  *) 
{*  Calls  EXFQSIZE.  *) 


BEGIN 

EXPOLENGTH  :=  EXPOSIZE (WORDSUSED) ; 

FLOATVJORDIIO  :=  1; 

EXPGIQRDBITS  :=  WORDSIZE; 

WHILE  ( EXPOWORDBITS  <  EXPOLENGTH)  DO  BEGIN 
EXFOWORDBITS  :=  EXPOWORDBITS  +  WORDSIZE; 

FIOMMORDND  :=  FLQATWORDND  +  1; 

END;  (*  IVHILE  *) 

FLCftTBITND  :=  (EXPCWORIBITS  -  EXPCXENGTH)  *  fDRESIGBIT  +  LSBIINO 
+  2  *  LESSSIGBIT; 

END;  (*  FIND1STFRACBIT  *) 

(***★***•»**) 

PROCEDURE  SETSIGBITS;  (*  Takes  the  values  of  WORDSUSED  and  *) 

(*  IITTBITCOUWr  and  uses  than  to  determine  the  *) 
(*  number  of  significant  bits  in  an  integer  *) 
(*  argument  which  is  to  be  converted  to  a  real.*) 
(*  Then  it  checks  to  see  if  the  real  number  *) 
(*  will  have  enough  space  for  its  exponent  plus*) 
(*  all  the  significant  bits  from  the  integer  if*) 
(*  the  same  precision  is  used  for  both.  If  not*) 
(*  then  IUTBITCOUMT  is  set  so  that  the  neces-  *) 
(*  sary  number  of  bits  of  precision  will  be  *) 
(*  truncated  from  the  real  number  and  a  warning*) 
(*  message  informs  the  user  that  sane  precision*) 
{*  has  been  lost.  *) 

(*  Uses  PRECISION,  WORDSUSED,  WORDSIZE,  *) 

(*  INIBITOOUNT,  ERR,  EXPOLENGTH.  *) 

BEGIN 

PRECISION  :*  WORDSUSED  *  WORDSIZE; 

INIBITCOUNT  :=  PRECISION  -  INTBITCOUNT; 

IF  ( ( INTBITCCUMT  +  EXPOLENGTH  +  1)  >  PRECISION)  THEN  BEGIN 
ERR  :=  SIGNIFICANCELOST; 

INIBITOOUNT  :=  PRECISION  -  EXPOLENGTH  -  1; 

END;  (*  IF  *) 

END;  (*  SETSIGBITS  *) 
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(**********) 


PROCEDURE  COPYEXPO ;  (*  Copies  an  exponent  from  ARG[3]  to  the  argument*) 

(*  in  the  ARG  specified  by  ARGNO.  The  exponent  *) 
(*  in  ARG[3]  is  expected  to  begin  in  word  1  and  *) 
{*  the  least  significant  bit  is  expected  to  be  *) 
(*  right  justified  to  a  word  boundary.  The  *) 
{*  argument  specified  t jy  ARGNO  is  a  real  number  *) 
(*  occupying  an  integral  number  of  full  words.  *) 
(*  Hence  the  copving  begins  at  the  bit  following  *) 
(*  the  sign  bit  and  continues  to  the  end  of  the  *) 
(*  exponent.  Each  bit  is  copied  one  at  a  time.  *) 
(*  Uses  5XPW0RDN0,  EXPBITNO,  EXFOLENGTH,  MSBITNO,*) 
{*  WORDSIZE,  FLOATS ITNO,  FLOATWORDNO,  BITCOUNT,  *) 
(*  ARGNO,  MORESIGBIT,  LSBITNO,  LESSSIGBIT.  *) 

l*  Calls  WRITEBIT,  CHKL05 DRDEND .  *) 

BEGIN 

EXFWORDID  :=  1; 

BITCOUNT  :=  EXPOLENGTH; 

WHILE  (BITCOUNT  >  WORDSIZE)  DO  BEGIN 
BITCOUNT  :=  BITCOUNT  -  MORDSIZE; 

EXPWORDID  :=  EXFWORDNO  +  1; 

END;  (*  WHILE  *) 

EXPBITND  ;=  BITCOUNT  *  fDRESIGBIT  +  LSBITNO  +  LESSSIGBIT; 

FLQATBITNO  :=  MSBITNO  +  LESSSIGBIT; 

FLOATWORDNO  :=  1; 

FOR  BITCOUNT  :=  1  TO  EXPOLENGTH  DO  BEGIN 

WRITEBIT ( 3 , EXHTORDIC, EXPBITNO, ARGNO, FLQAH JORDK) , FLQATBITNO)  ; 
CHKLCMDRDQJD  ( FLOATI^ORDNO, FLQATBITNO)  ; 

CHKLOtGRDEND  ( EXPMQRDNO ,  EXPBITNO ) ; 

END;  (*  FOR  *) 

END;  (*  COPYEXPO  *) 

(**********) 
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FUNCTION  PCWEROF(BASE:  INTEGER;  (*  Takes  a  base  and  exponent  as  *) 
EXPONENT:  INTEGER) :  INTEGER;  (*  calling  parameters  and  performs  *) 

(*  the  operation  of  exponentiation  *) 
(*  by  using  the  base  as  a  factor  *) 
(*  the  exponent  number  of  times.  *) 
(*  Uses  COUNTER.  *) 
(*  Known  BUGS  -  only  works  for  non-*) 
(*  negative  integers  which  can  be  *) 
(*  held  in  one  word.  *) 


VAR 

PRODUCT:  INTEGER; 

BEGIN 

PRODUCT  :=  1; 

COUNTER  :=  1; 

WHILE  (COUNTER  <=  EXPONENT)  DO  BEGIN 
PRODUCT  :=  PRODUCT  *  BASE; 
COUNTER  :=  COUNTER  +  1; 

END;  (*  WHILE  *) 

POWEROF  :=  PRODUCT; 

END;  (*  POWEROF  *) 

(**********) 


PROCEDURE  CALCEXPO;  {*  Determines  the  appropriate  bias  for  the  *) 

(*  exponent  of  a  real  number  based  on  the  *) 
(*  number  of  bits  in  the  exponent.  The  *) 
(*  algorithm  used  is  2  to  the  power  of  one  *) 
(*  less  than  the  number  of  bits  in  the  *) 
(*  exponent,  then  subtract  1  from  the  *) 
(*  result.  This  determines  the  exponent  *) 
(*  bias.  Then  the  value  of  the  exponent,  *) 
(*  determined  from  the  value  of  *) 
(*  INTBITCOUNT,  is  added  to  the  bias,  *) 
(*  resulting  in  the  value  which  is  actually*) 
(*  to  be  stored  in  the  exponent  of  the  real*) 
(*  number.  This  value  is  written  to  *) 
{*  ARG(3] .  *) 
(*  Uses  INIBASE,  EXP,  EXFOLENGTH,  EXP3IAS,  *) 
(*  INIBITCOUNT,  ARG.  *) 
(*  Calls  PCWERQF,  *) 
(*  Known  BUGS  -  only  works  for  values  which*) 
(*  can  be  held  in  one  word  because  POWEROF  *) 
(*  works  for  arguments  of  only  one  word.  *) 


BEGIN 

INTBASE  :=  2; 

EXP  :■  EXPOLENGTH  -  1; 

EXPBIAS  :=  POWEROF (INIBASE, EXP)  -  1; 
EXP  :=  EXPBIAS  +  INTBITCOUNT; 
ARG.INT[3,1]  :=  EXP; 

END;  (*  CALCEXPO  *) 

******** 
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PROCEDURE  INTDECREASE; 

BEGIN 

END;  (*  INTDECREASE  *) 

(***★*****★) 

PROCEDURE  RELDECREASE; 

BEGIN 

END;  (*  RELDECREASE  *) 
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(********************************* ft******************************************) 

(*  *) 

(*  MATHPAK  "FUNCTIONS"  *) 

(*  *) 

(  ***********************iHr***************************************************j 


PROCEDURE  FLOAT  (ARGNUM:  ARGINDEX) ;  (* 

(* 

(* 

<* 

(* 

(* 

(* 

(* 

{* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

<* 

(* 

(* 

(* 

(* 

(* 

(* 

{* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 

(* 


Changes  a  number  from  an  integer  *) 
representation  to  a  floating  *) 
point  representation.  It  works  *) 
on  an  argument  which  is  on  the  *) 
stack  (preceded  by  a  word  indica-*) 
ting  its  precision) .  It  pops  the*) 
integer  argument  off  the  stack  *) 
and  into  ARG[3] .  If  the  entire  *) 
argument  is  zero,  then  it  makes  *) 
no  change  in  representation.  If  *) 
not  zero,  it  checks  to  see  if  the*) 
argument  is  negative  and,  if  so,  *) 
changes  all  but  the  sign  to  the  *) 
corresponding  positive  represen-  *) 
tation.  Then  it  finds  the  most  *) 
significant  non-zero  bit  and  *) 
determines  the  number  of  *) 
significant  bits  in  the  integer.  *) 
It  writes  these  significant  bits  *) 
one  at  a  time,  from  most  to  least*) 
significant,  into  the  fractional  *) 
part  of  the  real  r presentation  *) 
in  the  ARC  specified  by  ARGNUM.  *) 
It  fills  the  fraction  with  zeroes*) 


to  the  next  word  boundary,  if  *) 
necessary.  It  writes  the  *) 
appropriate  exponent  and  sign  *) 
into  the  real  representation  to  *) 
make  it  complete.  It  also  sets  *) 
WORDS  for  the  ARC  specified  by  *) 
ARGNUM.  *) 
Uses  INIWORDNO,  FLQATWDRDNO,  *) 
MSBITND,  INTBITID,  INTBITCOUNT,  *) 
WORDNO,  WORDSUSED,  ARC,  ARGNO,  *) 
WORDS,  FLOATBITND,  LSBITNO,  *) 
LESSSIGBIT.  *) 
Calls  IOTBITREP,  GETSTATZERO,  *) 
WRITEBIT,  FINDNONOBIT,  CALCEXPO,  *) 
FIND1STFRACBIT,  SETSIGBITS,  *) 
BITSTOBITS,  BITVALFILL,  COPYEXFO,*) 
ABSVALIOT.  *) 
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BEGIN 

INIBITREP(3); 

ARG1D  :=  ARGNUM; 

WORDS [ARGNUM]  :=  VGRDSUSED; 

IF  (GETSTATZERO  =  TRUE)  THEN  BEGIN 
FOR  WORD!  JO  :=  1  TO  WORDSUSED  DO 
ARC. INT[ ARGNUM, WORDtD]  :=  0; 

END  (*  IF  *) 

ELSE  BEGIN 

INIW0RDN0  :=  1; 

FLQATMORDNO  :=  1; 

WRITEBIT (3,1, MSBITNO , ARGNUM , 1 , MSBITNO) ; 

IF  (ARG.INT(3,1]  <  0)  THEM  BEGIN 
ABSVALINT  ( 3 , WORDS [ 3 j ) ; 

END;  (*  IF  *) 

INTBITNO  :=  MSBITNO  +  LESSSIGBIT; 

INTBITCOUNT  :=  1; 

FINDNONOBIT(3)  ; 

FIND1STFRACBIT; 

SE7TSIGBITS; 

BITSTCBITS  (INTBITCOUNT,  3 ,  INTWORDNO,  INIBIINO ,  ARGNO ,  FLQATWORDNO , 
FLQATBITND) ; 

BITVALFILL  ( FALSE ,  ARGND ,  FLQATWORDNO ,  FLQATBITOO ,  WORDSUSED ,  LSBITNO) 
CALC  EXPO; 

COPYEXPO; 

END;  (*  ELSE  *) 

END;  (*  FLOAT  *) 


(****★♦****) 


PROCEDURE  RELTOINT; 

BEGIN 

EtD;  (*  RELTOINT  *) 

(**********) 
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AD-AU5  557  AIR  FORCE  INST  OF  TECH  WRIGHT-PATTER50N  AFB  OH  SCHOO— ETC  F/G  9/2 
ARBITRARY  PRECISION  IN  A  PRELIMINARY  MATH  UNIT  FOR  ADA.CU) 

MAR  82  P  K  LAWLIS 

UNCLASSIFIED  AFIT/GCS/MA/82M-2  NL 


PROCEDURE  INTSIZECHANGE;  (*  Gets  a  word  containing  the  precision  for  *) 

(*  the  new  integer  argument  from  the  top  of  *) 
(*  the  stack.  Then  gets  a  word  containing  the*) 
(*  present  precision  of  the  argument  from  the  *) 
{*  next  location  on  the  stack.  Then  takes  the*) 


(*  argument  from  the  stack  and  places  it  in  *) 
(*  ARG[1] .  Changes  its  precision  so  that  it  *) 
(*  has  the  desired  new  precision  (plus  up  to  *) 
(*  the  next  word  boundary  if  precision  re-  *) 
(*  quested  was  not  an  even  number  of  words) ,  *) 
(*  and  leaves  it  in  ARG(l).  Leaves  the  stack  *) 
(*  pointer  pointing  to  the  next  word  after  *) 
(*  the  argument  on  the  stack.  *) 
(*  Uses  WORDS.  *) 
(*  Calls  GETNEWSIZE,  INTBITREP,  IN1DECREASE,  *) 
(*  SAMEINTPRECISION.  *) 


BEGIN 

GETNEWSIZE; 

INTBITREP  (1) ; 

IF  (WORDS[2)  <  WORDS[l])  THEM 
IMDECREASE 

E)LS£ 

SAMEINTPRECISION; 

END;  (*  INTSIZECHANGE  *) 

(********♦★) 

PROCEDURE  RELSIZECHAt'JGE;  (*  Gets  a  word  containing  the  precision  for  *) 

(*  the  new  real  argument  from  the  top  of  the  *) 
(*  stack.  Then  gets  a  word  containing  the  *) 
(*  present  precision  of  the  argument  from  the  *) 
(*  next  location  on  the  stack.  Then  takes  the*) 


(*  argument  from  the  stack  and  places  it  in  *) 
(*  ARG[1] .  Changes  its  precision  so  that  it  *) 
(*  has  the  desired  new  precision  (plus  up  to  *) 
(*  the  next  word  boundary  if  precision  re-  *) 
( *  quested  was  not  an  even  number  of  words) ,  *) 
(*  and  leaves  it  in  ARG[1] .  Leaves  the  stack  *) 
(*  pointer  pointing  to  the  next  word  after  the*) 
(*  argument  on  the  stack.  *) 
(*  Uses  WORDS.  *) 
(*  Calls  GETNEWSIZE,  RELBITREP,  RELDBCREASE,  *) 
(*  SAMERELPRECI SION.  *) 


BEGIN 

GETNEWSIZE; 

REX£ITREP(1) ; 

IF  (WORDS (2]  <  WORDS [1] )  THEN 
REIDECREASE 

ELSE 

SAMERELPRECISION; 

END;  (*  RELS I Z ECHAMGE  *) 
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(**********) 


PROCEDURE  ABSVALI; 

BEGIN 

END;  {*  ABSVALI  *) 

(**********) 


PROCEDURE  ABSVALR; 

BEGIN 

END;  (*  ABSVALR  *) 

(**********) 


PROCEDURE  PLUSH;  (*  Takes  two  integer  arguments  from  the  stack  *) 

(*  (each  preceded  by  a  word  indicating  its  *) 
(*  precision) ,  adds  than  together,  and  leaves  the*) 
(*  result  of  the  addition  in  AF5G[1J.  The  *) 
(*  arguments  are  placed  in  ARG[2]  and  ARG[1],  *) 
(*  respectively,  when  popped  from  the  stack.  *) 
(*  A  check  is  also  made  to  see  if  the  two  *) 
(*  arguments  have  the  same  precision,  and  if  not,*) 
(*  then  the  one  of  least  precision  has  its  *) 
(*  representation  increased  to  match  the  other.  *) 
(*  The  result  has  the  precision  of  the  argument  *) 
(*  with  the  greatest  precision.  *) 
(*  Uses  no  variables.  *) 


(*  Calls  INTBITREP,  SAMEINTPRECISION,  ADDARGS.  *) 

BEGIN 

INTBITREP<2)  ; 

INTBITREP(l) ; 

SAMEINTPRECISION ; 

ADDARGS (1) ; 

END;  (*  PLUSII  *) 

(★****♦****) 
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PROCEDURE  PLUSRR; 


BEGIN 

RELBITREP(2) ; 
RELBITREP(l) ; 
SAMERELPRECI  SION ; 
ADDARGS(2) | 

END;  (*  PLUSRR  *) 


PROCEDURE  PUJSIR; 


BEGIN 

RELBITREP(2) ; 
FLQAT(l) ; 
SAMERELPRECI  SION ; 
AODARGS(2) ; 

END;  (*  PLUSIR  *) 


(*  Takes  two  real  arguments  from  the  stack  (each  *) 
(*  preceded  by  a  word  indicating  its  precison) ,  *) 
(*  adds  them  together,  and  places  the  result  of  *) 
(*  the  addition  in  ARG[1J.  The  two  arguments  *) 
(*  are  placed  in  ARG(21  and  ARG(1],  respectively,*) 
(*  when  popped  from  the  stack.  A  check  is  also  *) 
{*  made  to  see  if  the  arguments  have  the  same  *) 
(*  precision,  and  if  not,  then  the  one  of  least  *) 
(*  precision  has  its  representation  increased  to  *) 
(*  match  the  other.  The  result  has  the  precision*) 
(*  of  the  argument  with  the  greatest  precison.  *) 
(*  Uses  no  variables.  *) 
(*  Calls  REIEITREP,  SAMERELPRECISION,  ADOARGS.  *) 


(****★**★**) 

(*  First  takes  a  real  argument  from  the  top  of  *) 
(*  the  stack  (preceded  by  a  word  indicating  its  *) 
(*  precision) ,  and  reads  it  into  ARG[2] .  Then  *) 
(*  it  takes  an  integer  argument  from  the  top  of  *) 
(*  stack  (also  preceded  by  a  word  indicating  its*) 
(*  precision) ,  changes  its  representation  to  *) 
(*  floating  point,  and  puts  it  in  ARG[1] .  Then  *) 
(*  it  checks  to  see  if  the  arguments  have  the  *) 
(*  same  precision,  and  if  not,  then  the  one  of  *) 
(*  least  precision  has  its  precision  increased  *) 
(*  to  match  the  other.  The  arguments  are  then  *) 


(*  added  together.  The  result  is  a  floating  *) 
(*  argument  in  ARG[1]  with  a  precision  the  same  *) 
(*  as  the  argument  with  greatest  precision.  *) 
(*  Uses  no  variables.  *) 
(*  Calls  RELBITREP,  FLOAT,  SAMERELPRECISION,  *) 
(*  ADDARGS.  *) 


(*********  *) 
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PROCEDURE  PLUSRI; 


(*  First  takes  an  integer  argument  from  the  top  *) 
{*  of  the  stack  (preceded  by  a  word  indicating  *) 
(*  its  precision),  changes  its  representation  to  *) 
(*  floating  point,  and  puts  it  in  ARG[2J.  Then  *) 
(*  it  takes  a  real  argument  from  the  top  of  the  *) 
(*  stack  (also  preceded  by  a  word  indicating  its  *) 


(*  precision)  and  puts  it  in  ARG(11.  Then  it  *) 
{*  checks  to  see  if  the  arguments  have  the  same  *) 
(*  precision,  and  if  not,  it  changes  the  *) 
(*  representation  of  the  argument  of  least  *) 
(*  precision  to  make  its  precision  match  the  *) 
(*  other.  Then  it  adds  the  arguments  together.  *) 
(*  The  result  is  a  floating  argument  in  ARG[1]  *) 
(*  with  the  same  precision  as  the  argument  of  *) 
(*  greatest  precision.  *) 
{*  Uses  no  variables.  *) 
(*  Calls  FLOAT,  REL8ITREP,  SATIERELPRECISION,  *) 
(*  ADDARGS.  *) 


BEGIN 
FLQAT(2) ; 
RELBITREP(l)  ; 
SAMERELPRECI SION ; 
ADDARGS(2) ; 

END;  (*  PLUSRI  *) 


(*★*★******) 


PROCEDURE  PLUSI; 


BEGIN 

INTBITREP(l) ; 
END;  (*  PLUSI  *) 


(*  Takes  an  integer  argument  from  the  top  of  the  *) 


<*  stack  (preceded  by  a  word  indicating  its  *) 
(*  precision)  and  puts  it  in  ARG(l] .  *) 
(*  Uses  no  variables.  *) 
(*  Calls  INTBITREP.  *) 


(********♦♦) 


PROCEDURE  PLUSR; 


BEGIN 

RELBITREP(l) ; 
END;  <*  PLUSR  *) 


(*  Takes  a  real  argument  from  the  top  of  the  *) 
(*  stack  (preceded  by  a  word  indicating  its  *) 
(*  precision)  and  puts  it  in  ARG[1] .  *) 
(*  Uses  no  variables.  *) 
(*  Calls  RELBITREP.  *) 


(**★******★) 
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PROCEDURE  MINUSII 


(*  Same  aeration  as  PLUSH  except  that  *) 
(*  ARG(2]  is  complemented  before  the  *) 
(*  addition  is  performed.  *) 
{*  Uses  WORDS.  *) 
(*  Calls  INIBITREP,  CGMPLMEMT,  ADDARGS,  *} 
{*  SAMEINTPRECISIOU.  *) 


BEGIN 

INIBITREP (2) ; 

C0MPU1ENT(2,I'3ORDSl2] ) ; 

INTBITREP(l) ; 

SAMEINEPRECISION  ; 

ADDARGS (1) ; 

END;  (*  MINUSII  *) 

(**********) 

PROCEDURE  MINUSRR;  (*  Same  operation  as  PLUSRR  except  that  the  *) 


(*  sign  of  ARG[2]  is  changed  before  the  *) 
(*  addition  is  performed.  *) 
(*  Uses  ARG,  MSBITNO.  *) 
(*  Calls  RELBITREP,  SAMERELPRECISION,  *) 
(*  ADDARGS.  *) 
(*  Possible  BUGS  -  ARG  will  need  to  be  *) 
(*  unpacked  or  masked  in  Standard  Pascal  to  *) 
(*  make  the  M)T  work  properly.  *) 


BEGIN 

RELBITREP (2) ; 

ARG  .BIT  [2,1,  MSBITNO  ]  :=  NOT  ARG.BIT[2, 1, MSBITNO] ; 
RELBITREP  ( 1)  ; 

SAMERELPRECISION ; 

ADDARGS (2) ; 

END;  (*  MINUSRR  *) 

(**********) 


PROCEDURE  MINUSIR;  (*  Same  operation  as  PLUSIR  except  that  the  *) 

(*  sign  of  ARG [2]  is  changed  before  the  *) 
(*  addition  is  performed.  *) 
(*  Uses  ARG,  MSBITNO.  *) 
{*  Calls  RELBITREP,  FLOAT,  SAMERELPRECISION,  *) 
(*  ADDARGS.  *) 
(*  Possible  BUGS  -  ARG  will  need  to  be  *) 
(*  unpacked  or  masked  in  Standard  Pascal  to  *) 
(*  make  the  NOT  work  properly.  *) 


BEGIN 

RELBITREP (2) ; 

ARG. BIT [2,1, MSBITNO]  :=  MOT  ARG.BIT [2,1, MSBITNO] ; 
FLOAT(l) ; 

SAMERELPRECISION; 

ADDARGS (2) ; 

END;  (*  MINUSIR  *) 
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(★******★**) 


PROCEDURE  MINUSRI ;  (*  Same  operation  as  PLUSRI  except  that  the  *) 

(*  sign  of  ARC [21  is  changed  before  the  *) 
(*  addition  is  performed.  *) 
(*  Uses  ARC,  MSBITNO.  *) 
(*  Calls  FLOAT,  RELBITREP,  SAMERELPRECISION,  *) 
(*  ADDARGS.  *) 
(*  Possible  BUGS  -  ARG  will  need  to  be  *) 
(*  unpacked  or  masked  in  Standard  Pascal  to  *) 
(*  make  the  tOT  work  properly.  *) 


BEGIN 
FLOAT (2) ; 

ARG. BIT(2,1, MSBITNO]  :=  NOT  ARG.BIT [2,1, MSBITNO] ; 
RELBITREP (1) ; 

SAMERELPRECI  SION; 

ADDARGS (2)  ; 

END;  (*  MIKUSRI  *) 


(*  ******** 

PROCEDURE  MINUSI ;  (*  Same  as  PLUSI  except  that  it  complements  *) 

(*  the  integer.  *) 

(*  Uses  WORDS.  *) 

(*  Calls  INTBITREP,  COMPU'ENT.  *) 

BEGIN 

INTBITREP(l) ; 

C0MPU1EOT(1,W0RDS[1]) ; 

END;  (*  minusi  *) 


(******★★**) 


PROCEDURE  MINUSR;  (*  Same  as  PLUSR  except  that  the  sign  is  changed  *) 

(*  Uses  ARG,  MSBITNO.  *) 

(*  Calls  RELBITREP.  *) 


(*  Possible  BUGS  -  ARG  will  need  to  be  unpacked  *) 
{*  or  masked  in  Standard  Pascal  to  make  the  NOT  *) 
(*  work  properly.  *) 

BEGIN 

RELBITREP (1) ; 

ARG. BIT [1,1, MSBITNO]  :=  NOT  ARG. BIT[1,1, MSBITNO] ; 

END;  (*  MINUSR  *) 


(♦*****#***) 


PROCEDURE  MULTI I; 
BEGIN 

EJD;  (*  MULTI  I  *) 


(*★****♦***) 
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PROCEDURE  MULTRRf 
BEGIN 

END;  (*  MJL1RR  *) 

^*  ********  *^ 


PROCEDURE  MULTIR; 
BEGIN 

QD;  (*  MULTIR  *) 


^*  ********  *j 


PROCEDURE  MUL1RI; 
BEGIN 

END;  (*  MULTRI  *) 


(**********) 


PROCEDURE  DIVII; 
BEGIN 

EM);  (*  DIVII  *) 


(**********) 


PROCEDURE  DIVRR; 
BEGIN 

END;  (*  DIVRR  *) 


^*  ******** 


PROCEDURE  DIVIR; 
BEGIN 

END;  (*  DIVIR  *) 


(**********) 


PROCEDURE  DIVRI; 
BEGIN 

END;  (*  DIVRI  *) 


(*★♦*******) 


PROCEDURE  REMI ; 
BEGIN 

EUD;  (*  REMI  *) 


^*  ********  *^ 
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r 


PROCEDURE  MODI; 
BEGIN 

END;  (*  MODI  *) 


(**********) 


PROCEDURE  PCMERII; 

BEGIN 

END;  (*  PaTERII  *) 

(**********) 


PROCEDURE  PCWERRR; 

BEGIN 

END;  (*  PCWERRR  *) 

(**★***»***) 


PROCEDURE  POWERIR; 

BEGIN 

END;  (*  POWERIR  *) 

(*******♦★*) 


PROCEDURE  PCJWERRI; 

BEGIN 

END;  (*  Pa/ERRI  *) 

(**********) 


PROCEDURE  SQRTI; 
BEGIN 

END;  (*  SQRTI  *) 


(*♦****♦***) 


PROCEDURE  SQRTR; 
BEGIN 

END;  (*  SQRTR  *) 


;♦**♦******) 


PROCEDURE  EXPI; 
BEGIN 

END;  (*  EXPI  *) 


{*★*******♦) 
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PROCEDURE  EXPR; 

BEGIN 

END;  (*  EXPR  *) 

(****★**★**) 

PROCEDURE  LOGI; 

BEGIN 

END;  (*  LOGI  *) 

(***★*★****) 

PROCEDURE  LOGR; 

BEGIN 

END;  (*  LOGR  *) 

(**********) 

PROCEDURE  LNI; 

BEGIN 

END;  (*  LNI  *) 

{*******★★*) 

PROCEDURE  LNR; 

BEGIN 

END;  (*  LNR  *) 

(**********) 

PROCEDURE  SINI; 

BEGIN 

END;  (*  SINI  *) 

(**********) 

PROCEDURE  SINR; 

BEGIN 

END;  (*  SINR  *) 

(**********) 

PROCEDURE  COSI; 

BEGIN 

END;  (*  COSI  *) 

(*****★♦***) 
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PROCEDURE  COSR; 

BEGIN 

EM);  (*  COSR  *) 

(***★*****★) 

PROCEDURE  TAN I ; 

BEGIN 

El©;  (*  TANI  *) 

********  *j 

PROCEDURE  TAI»; 

BEGIN 

EtD;  (*  TANR  *) 

(**********) 

PROCEDURE  ARCSINI; 

BEGIN 

END;  (*  ARCSINI  *) 

(**********) 


PROCEDURE  ARCSINR; 

BEGIN 

END;  (*  ARCSINR  *) 

(******♦*★*) 


PROCEDURE  ARCCOSI; 
BEGIN 

END;  (*  ARCCOSI  *) 


(**********) 


PROCEDURE  ARCCOSR; 

BEGIN 

END;  (*  ARCCOSR  *) 

(**********) 

PROCEDURE  ARCTANI; 

BEGIN 

END;  (*  ARCTANI  *) 


(**********) 
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PROCEDURE  ARCTANR; 
BEGIN 

END;  (*  ARCTANR  *) 


(★*★*******) 


PROCEDURE  SINHI; 
BEGIN 

END;  (*  SINHI  *) 


(**★***★***) 


PROCEDURE  SINHR; 
BEGIN 

END;  (*  SINHR  *) 


{**********) 


PROCEDURE  CQSHI; 
BEGIN 

EEC;  (*  COSHI  *} 


(******★*♦*) 


PROCEDURE  COS HR; 
BEGIN 

END;  (*  COS HR  *) 


(**********) 


PROCEDURE  TANHI; 
BEGIN 

END;  (*  TANHI  *) 


(♦***♦*****) 


PROCEDURE  TANHR; 
BEGIN 

END;  (*  TANHR  *) 
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(****************************************************************************) 
(  ******* *****************  ***********  *  ****************************************} 


( ****************************************************************************) 
(*  *> 
(*  MAIN  MATHPAK  EXECUTION  *) 

(*  .  *) 
( **********************************************************★*★***************) 


BEGIN 

INITMASKS ; 

ERR  !=  NOERROR; 
ERRCODE  :=  0; 

CASE  FUNCCODE  OF 
1:  FLQAT(l) ; 

2:  RELTOINT; 

3;  HITS  I ZECHANGE ; 
4:  RELSIZECHANGE; 
5:  ABSVALI; 

6:  ABSVALR; 

21:  PLUSII; 

22:  PLUSRR; 

23:  PLUSIR; 

24:  PLUSRI; 

25:  PLUSI; 

26:  PLUSR; 

41:  MINUSII; 

42:  KINUSRR; 

43:  KINUSIR; 

44:  MINUSRI; 

45:  MINUSI; 

46:  HINUSR; 

61:  MULTI I; 

62:  KULTRR; 

63:  MULTIR; 

64:  MULTRI; 

81:  DIVII; 

82:  DIVRR; 

83:  DIVTR; 

84:  DIVRI; 

85:  RJE*II; 

95:  MODI; 

101:  Pa/ERII; 

102:  POWERRR; 

103:  PCV7ERIR; 

104:  PCWERRI; 

115:  SQKII; 

116:  SQRTR; 

125:  EXPI; 
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126:  EXPR; 

145:  LOGI; 

146:  LOGR; 

155:  LNI; 

156:  LNR; 

165:  SINI; 

166:  SINR; 

175:  COS^- 
ne:  COSR; 

185:  TAI'JI; 

186:  TANR; 

195:  ARCSINI; 

196:  ARCSINR; 

205:  ARCCOSI; 

206:  ARCCX)SR; 

215:  ARCTANI; 

216:  ARCTANR; 

225:  SINHI; 

226:  SINHR; 

235:  COSHI; 

236:  COS HR; 

245:  TANHI; 

246:  TANHR; 

END;  (*  CASE  *) 
PUSHARG(l) ; 

IF  (ORD(ERR)  >  0)  THEM 
ERRCODE  :=  ORD(ERR)  ; 

END;  (*  MATHPAK  *) 


99 


APPENDIX  D 


IHHMMT  Listing 


(ft***-************************************************************************) 
j  *********************************************************** *****************^ 
( **  **) 
(**  P  A  C  K  A  G  E  IMPLMEHT  **) 
(**  **) 
( I****************************************************************************) 

( *★★*★★★★★★★*****★**★★**★****★*★★★★★★★*****★**★*★*★*★★★★***★*★*★★*★★****★★**★ j 


PROCEDURE  IMPLMEHT ( niCTICtlCODE :  INTEGER;  VAR  STACKPOINTER,  ERROROODE;  INTEGER) 


(  ******** * *****  **  ***********  *************************************************) 


(*  This  is  a  Pascal  Procedure  which  is  meant  to  correspond  to  an  Adi  Package. 
The  code  is  written  in  Pascal,  but  it  is  written  as  much  like  Ada  as  possible 
so  that  it  can  be  translated  into  Ada.  *) 


(*  This  Package  is  designed  to  be  used  in  conjunction  v/ith  Package  MATHPAK. 

It  does  business  in  essentially  the  same  manner  as  MATHPAK.  It  contains 
those  routines  which  may  be  done  differently  for  different  implementations 
but  can  be  done  this  way  for  any  implementation.  These  routines  could 
be  written  in  some  other  language,  such  as  machine  language.  As  a  separate 
package  they  allow  for  an  increase  in  efficiency  where  the  particular  machine 
instruction  set  or  hardware  capabilities  can  be  exploited  to  that  end.  If 
an  implementation  creates  its  own  version  of  IMPLMENT,  that  version  must 
provide  the  same  interface  with  MATHPAK  as  this  one.  *) 

(*  These  routines  were  developed  on  the  Apple  II,  but  when  completed  they 
should  be  implementation  independent.  They  only  require  that  the  constants 
be  set  properly  for  the  environment,  in  the  same  manner  as,  and  consistent 
with  the  constants  of  MATHPAK. 
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CONST  (*  Constants  must  be  set  to  correspond  to  the  *) 

{*  environment  -  and  MAIHPAK  *) 

iv’ORDLQJGTH  =  16;  (*  Hunger  of  bits  in  a  machine  word  used  to  *) 

(*  perform  integer  operations  *) 

LSBITiWI-i  =  0;  (*  The  number  of  the  least  significant  bit  of  an  *) 

(*  integer  word  *) 

MSBIT1WM  =15;  (*  The  number  of  the  most  significant  bit  of  an  *) 

(*  integer  word  *) 

BITLESS  =  -1;  (*  One  less  than  the  smallest  legal  bit  number  of  *) 

{*  an  integer  word  *) 

BITMORE  =16;  (*  One  more  than  the  largest  legal  bit  number  of  *) 

(*  an  integer  word  *) 

BYTESIZE  =  255;  (*  Largest  number  which  can  be  held  in  a  half  word*) 

BITSPERBYTE  =8;  ( *  Number  of  bits  in  a  half  word  *) 

UPSTAK  =  -1;  (*  -1  if  stack  built  from  high  memory  (bottom)  to  *) 


(*  low  memory  (top)  and  +1  if  stack  built  opposite*) 
DCVJliSTAX  =  1;  (*  +1  if  stack  built  from  high  memory  (bottom)  to  *) 

(*  low  memory  (top)  and  -1  if  stack  built  opposite*) 
/iORSIGBIT  =1;  (*  +1  if  bits  in  a  word  are  numbered  from  least  *) 

(*  significant  (lowest  number)  to  most  significant*) 


(*  (highest  number)  and  -1  if  bits  numbered  *) 

(*  opposite  way  *) 

LESSIGBIT  =  -1;  (*  -1  if  bits  in  a  word  are  numbered  from  least  *) 

(*  significant  (lowest  number)  to  most  significant*) 

(*  (highest  number)  and  +1  if  bits  numbered  *) 

(*  opposite  way  *) 

LAKGESTARG  =16;  (*  Largest  number  of  words  permitted  for  a  *) 

(*  numerical  argument  for  this  implementation  *) 

ilAXNLVNORDS  =17;  (*  One  more  than  LARGESTARG  *) 
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TYPE 

HAXBITNUMBER  =  BITLESS . . 5ITM0RE ; 

HAXJ.DRDS  *  0  .  .HAXNUMWORDS; 

ARGUINDEX  =  1..2; 

SIGNRESULT  =  ( EITHER, SAME) ; 

ERRORMESSAGE  »  ( NDERROR , CCNSTRAINTERROR , SIGHIFICANCELOST, OVERFLO? , 
UNDERFLOW ,  DIVT  SIONBYZERO . STORAGEERRDR)  ; 

BITNUMBER  =  LSBITNUM. .MSBITNUM; 

WORKWORDS  =  1..LARGESTARG; 

BYTENUMBER  =  0..1; 

BITE  =  0 . .BYTESIZE; 

REPS  =  (E,F,G,H) ; 

BYTEARAY  =  PACKED  ARRAY [BYTENUMBER]  OF  BITE; 

BITARAY  =  PACKED  ARRAY  [BITNUMBER]  OF  BOOLEAN; 


REGISTER  *  RECORD  CASE  REPS  OF 

(*  These  representations 

*) 

E:  (INT:  INTEGER)  ; 

(*  permit  IMPINENT  to 

*) 

F:  (BOOL:  BOOLEAN) ; 

(*  interpret  the  contents 

*) 

G:  (BYTE:  BYTEARAY); 

(*  of  the  "registers"  and 

*) 

H:  (BIT:  BITARAY); 

(* 

*) 

END; 

(* 

*) 

INTARAY  =  ARRAY [WORKWORDS]  OF  INTEGER; 
BOOLARAY  »  ARRAY [WORKWORDS]  OF  BOOLEAN; 
BITEARAY  =  ARRAY [WORKWORDS]  OF  BYTEARAY; 
BITTARAY  *  ARRAY  [VJORKVIORDS]  OF  BITARAY; 
WORKARRAY  =  RECORD  CASE  REPS  OF 

(*  arithmetic  working  area 

*) 

E:  (INT:  INTARAY); 

(*  any  way  it  wants. 

*) 

F:  (BOOL:  BOOLARAY) ; 

(*  This  makes  bit  and 

*) 

G:  (BYTE:  BITEARAY); 

(*  byte  manipulations 

*) 

H:  (BIT:  BITTARAY); 

(*  possible. 

*) 

END; 

(* 

*> 
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VAR 


NUMB IT, 

(* 

Indexes  for  bit 

*) 

BITNUM, 

(* 

*) 

BITNDi'l:  MAXBITNUMBER; 

<* 

*) 

BYTENUM:  BYTENUMBER; 

(* 

half  word 

*) 

WORDMJM, 

(* 

word 

*) 

NUM-JQRDS:  MAXWORDS; 

(* 

*) 

ARGUNUM, 

(* 

argument 

*) 

EXFNCJM:  ARGU INDEX; 

(* 

numbers 

*) 

BYTEMASK, 

(* 

"Registers" 

*) 

SIGNMASK, 

{* 

*) 

SIGN, 

(* 

*) 

ARITHRBG:  REGISTER; 

(* 

*) 

WORKAREA, 

(* 

Work  areas 

*) 

EXPVALUE, 

(* 

*) 

RESULT:  WORKARRAY; 

(* 

*) 

CARRY:  0..1; 

<* 

Carry  value 

*) 

EXPLENGTH, 

(* 

Real 

*) 

EXPPOINTER, 

(* 

number 

*) 

FRACLEMGTH, 

(* 

*) 

SHIFTNUM, 

(* 

information 

*) 

POINTER, 

<* 

Stack 

*) 

PTR, 

(* 

pointers 

*) 

KOUNT, 

(* 

General 

*) 

SIZE:  INTEGER; 

(* 

counters 

*> 

SIGUINDICATOR:  SIGNRESULT; 

(* 

For  testing  sign  of  result 

*> 

ERRORIIID:  ERRORMESSAGE; 

(* 

Error  message  holder 

*) 
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(  **********************************  **  irk  it  irk  It  Irk  irk  irk  irk  it  it  Irk  it  it  ********************J 
(  **************************************************************************** J 


(  ********************************************************* ******** * ********** J 
(*  *) 
(*  SUPPORT  ROUTINES  *) 
<*  *> 
| **************** *********************** ************* ************************ J 


PROCEDURE  SIGNINTADD;  (*  Checks  to  see  if  the  signs  of  the  two  numbers  *) 

(*  to  be  added  are  the  same.  If  not,  then  *) 
(*  SIGNINDICATOR  is  set  to  EITHER  to  indicate  *) 
(*  that  the  result  can  have  either  sign.  If  so,  *) 
(*  then  SIGNINDICATOR  is  set  to  SAME  to  indicate  *) 
(*  that  the  result  must  have  the  same  sign  as  *) 
(*  SIGN.  *) 
(*  Uses  WORKAREA,  S,  STACKPOIKTER ,  SIGN,  *) 
(*  SIGNMASK,  NUM-JORDS,  MSBITNUM,  SI®INDICATDR,  *) 
(*  DOWNSTAK.  *) 
(*  Possible  BUGS  -  WORKAREA  will  need  to  be  up-  *) 
(*  packed  or  masked  in  Standard  Pascal.  *) 


BEGIN 

WORKAREA.IOT[l]  :=  S[STACKPOIOTER] ; 

SIGN. BOOL  :=  WORKAREA. BOOL [1J  AtD  SIGNMASK.BOOL; 

WORKAREA.  INT{2]  :=  S(OTAQCFOIOTER+NUMWORDS*DClJWSrAK] ; 

IF  (WORKAREA. BIT ( 1 , MSBITNUM]  <>  WORKAREA. BIT [2, MSBITNUM])  THEN 
SIGNINDICATOR  :=  EITHER 

ELSE 

SIGNINDICATOR  :=  SAME; 

END;  (*  SIGNIMTADD  *) 


(^*  ********  *) 
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PROCEDURE  ADDGENERAL ;  (*  Performs  the  general  addition  function  on  *) 

(*  two  arguments.  Takes  one  word  at  a  time  *) 
(*  from  each  argument,  starting  with  the  *) 
(*  least  significant  word,  and  puts  one  word  *) 
(*  in  W0RKAREA[1J  and  the  other  in  *) 
(*  WORKAREA[2] .  Takes  one  byte  at  a  *) 
(*  time  from  each  word,  starting  with  the  *) 
{*  least  significant  byte  of  each  word.  Adds*) 
{*  in  the  carry  fran  previous  bytes  added  *) 
(*  using  CARRY.  Places  the  result  in  the  *) 
(*  corresponding  byte  of  the  RESULT  indexed  *) 
(*  by  WORDNUM .  Sets  CARRY  for  the  next  add,  *) 
(*  if  any.  Sets  the  STACKPOINTER  to  the  *) 
(*  location  immediately  following  the  *) 
(*  arguments  (effectively  having  popped  the  *) 
(*  arguments  from  the  stack) .  *) 
(*  Uses  BYTENUH,  ARITHREG,  BYTEMASK,  RESULT,  *) 
(*  WORKAREA,  CARRY,  ViDRDNUH,  NUHWORDS,  *) 
(*  POINTER,  STACKPOINTER,  PTR,  S,  DOWNSTAK,  *) 
(*  UPSTAK,  MOUNT,  BITSPERBYTE,  MORSIGBIT,  *) 
(*  LSBITNUM.  *) 
(*  Possible  BUGS  -  ARITHREG  and  WORKAREA  *) 
(*  will  need  to  be  unpacked  or  masked  in  *) 
(*  Standard  Pascal.  *) 


BEGIN 

CARRY  :=  0; 

WTORDNUM  :*  NUHWORDS; 

POINTER  :=  STACKPOINTER  +  NUHWORDS  *  DOWNSTAK  +  UPSTAK; 

PTR  :»  POINTER  +  2X2MWQRDS  *  DOWNSTAK; 

FOR  KOUNT  :=  1  TO  NUl-SJORDS  DO  BEGIN 
WORKAREA. IOT[2]  :=  SfPOIHTER]  ; 

WORKAREA.  INT[1]  :=  S[PTR]  ; 

FOR  BYTENUH  :*  0  TO  1  DO  BEGIN 

ARITHREG  .BYTE  [0  ]  :=  WORKAREA.  BYTE  [  1 ,  BYTENUH] ; 

ARITHREG. BOOL  ;*  ARITHREG. 3CGL  AND  BYTEMASK . BOOL ; 

WORKAREA. BYTE [3,0]  :=  WORKAREA. BYTE [2, BYTENUH ] ; 

WORKAREA. BOOL [ 3 ]  ;=  WORKAREA. BOOL [3]  AND  BYTEMASK . BOOL ; 
ARITHREG. INT  :*>  ARITHREG. IMT  +  WORKAREA . INT [ 3 ]  +  CARRY; 
WORKAREA . BYTE [ 4 , BYTENUH ]  :=  ARITHREG.BYTE[0] ; 

IF  (BYTENUH  =  0)  THIN  BEGIN 

RESULT . BOOL [WORDNUM ]  :■=  WORKAREA.BOOL[4]  AND  BYTEMASK. BOOL; 
END  (*  IF  *) 

ELSE  BEGIN 

WORKAREA. BOOL [4]  :=  WORKAREA. BOOL [4]  AND  NOT  BYTEMASK. BOOL; 
RESULT. BOOL [WORDNUM]  :=  RESULT . BOOL  [WORDNUM]  OR 
WORKAREA.  BOOL[4] ; 

El©;  (*  ELSE  *) 

IF  (ARITHREG .  BIT  [  LSBITNUK+BITSPEREYTE*f>DRSIGBIT]  «  TRUE) 

THEN  BEGIN 
CARRY  :=  1; 

ARITHREG . BIT [ LSBITTO'l+BITSPERBYTE*t'DRSIGBIT]  :*  FALSE; 

El©  (*  IF  *) 

ELSE 
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CARRY  :=  0; 

END;  {*  FOR  *) 

WORDNUM  :=  WQRDNUM  -  1; 

POINTER  :*  POINTER  +  UPSTAK; 

PIR  ;=  PTR  +  UPSTAK; 

END;  (*  FOR  *) 

STACKPOINTER  :=  STACKPOINTER  +  (2  *  WINWORDS  *  DOUNSTAK)  ; 
END;  (*  AEOGENERAL  *) 

(★********★) 


PROCEDURE  INTPREPADD;  (*  Performs  the  general  functions  required  *) 

(*  for  the  addition  of  two  integers.  Pops  *) 
{*  a  word  containing  the  number  of  *) 
(*  words  in  each  argument  from  the  top  of  *) 
(*  the  stack.  Then  calls  SIGNINTADD  to  *) 
(*  check  for  the  sign  to  expect  in  the  *) 
{*  result,  and  calls  ADDGENERAL  to  perform  *) 
(*  the  addition.  *) 
(*  Uses  NUI1IORDS,  S,  STACKPOINTER,  DOWNSTAK.*) 
(*  Calls  SIGNINTADD,  ADDGENERAL.  *) 


BEGIN 

NUHNORDS  :=  S  [STACKPOINTER  1  ; 

STACKPOINTER  :=  STACKPOINTER  +  DOWNSTAK; 

SIGNINTADD; 

ADDGENERAL; 

END;  (*  INTPREPADD  *) 

(**********) 

PROCEDURE  CHKH IWRDEI D ( VAR  NUI-DFWORD:  (*  Increments  the  value  of  the  *) 
MAXWORDS;  VAR  NUMOFBIT:  (*  bit  index,  NUMOFBIT,  and  *) 

MAXBITNUMBER) ;  (*  then  checks  to  see  if  its  *) 

(*  value  is  past  a  word  boun-  *) 
(*  aary.  If  so,  it  decrements  *) 
(*  the  word  number,  NUHDFVJORD,  *) 
(*  and  sets  NUMOFBIT  back  to  *) 
(*  the  value  of  the  least  sig-  *) 


(*  nificant  bit  of  a  word,  *) 
(*  LSEITNUM.  *) 
(*  Uses  MSBITNUM,  LSBITNUH,  *) 
(*  MORSIGBIT.  *) 


BEGIN 

NUMOFBIT  :=  NUMOFBIT  +  MORSIGBIT; 

IF  ( ( (NUIDFBIT  >  MSBITNUM)  AID  (MORSIGBIT  =1))  OR 

( (NUMOFDIT  <  MSBITNUM)  AID  (MORSIGBIT  =  -1)))  THEN  BEGIN 
WJMOFBIT  :=  LSBITNUM; 

NUMOFWORD  :=  NUMOFMORD  -  1; 

END;  (*  IF  *) 

END;  (*  CHKHIWRDiND  *) 

(★*★*******) 
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PROCEDURE  CHKLCWRDEND(VAR  NUMOFWQRD: 
MAXWORDS;  VAR  NUMDFBIT: 
MAXBITNUMBER) ; 


BEGIN 

NUMOFBIT  :=  NUMOFBIT  +  LESSIGEIT; 

IF  ( ( (NUMOFBIT  <  LSBITNUM)  AMD  (LESSIGBIT  =  -1))  OR 

( (NUHOFBIT  >  LSBITNUM)  AND  (LESSIGBIT  =1)))  THEN  BEGIN 
NUMOFBIT  :=  MSBITNUM; 

NUMOFWQRD  :=  NUMOEVJORD  +  1; 

END;  (*  IF  *) 

END;  (*  CHKLG'/RDEND  *) 

(******♦*★*) 


(*  Decrements  the  value  of  the  *) 
(*  bit  index,  NUMOFBIT,  and  *) 
(*  then  checks  to  see  if  its  *) 
(*  value  is  past  a  word  boun-  *) 
(*  dary.  If  so,  it  increments  *) 
(*  the  word  number,  NUI1DEWORD,  *) 
(*  and  sets  NUMOFBIT  back  to  *) 
(*  the  value  of  the  most  sig-  *) 


(*  nificant  bit  of  a  word,  *) 
(*  MSBITNUM.  *) 
(*  Uses  LSBITNUM,  MSBITNUM,  *) 
(*  LESSIGBIT.  *) 


PROCEDURE  RIGHTSHIFT(GLDWORD:  (*  Writes  the  bit  in  WORKAREA  indexed  *) 
MAXWORDS;  OLDBIT :  (*  by  OLDWORD  and  OLDBIT  to  NEWWORD  *) 

MAXBITNUMBER;  VAR  NEWWORD:  (*  and  NEWBIT.  OLDWORD  and  OLDBIT  *) 
MAXWDRDS;  VAR  NEWBIT:  (*  must  Degin  at  the  index  value  for  *) 

MAXBITNUMBER) ;  (*  the  least  significant  bit  to  be  *) 

(*  Shifted,  and  NEWWORD  and  NEIVBIT  *) 
(*  begin  at  the  index  values  for  the  *) 
(*  least  significant  destination  bit.  *) 
(*  Works  from  the  least  significant  *) 
(*  bit  up  and  shifts  the  number  of  *) 
(♦bits  specified  by  SHIFTNUM.  *) 

(*  Changes  index  values  as  it  goes  and*) 
{*  returns  the  final  value  of  NENMORD  *) 
(*  and  NEWBIT.  *) 

(*  Uses  SHIFTNUM,  WORKAREA.  *) 

(*  Calls  CHKHIWRDEND.  *) 

{*  Possible  BUGS  -  WORKAREA  will  need  *) 
(*  to  be  unpacked  or  masked  in  *) 

(*  Standard  Pascal.  *) 


BEGIN 

WHILE  (SHIFTNUM  >  0)  DO  BEGIN 

WORKAREA . BIT (NEWWORD , NEIVBIT)  :=  WORKAREA.BIT [OLDWORD, OLDBIT ] ; 
SHIFTNUM  :=  SHIFTJXJM  -  1; 

CHKH  IWRDEND ( OLDTORD , OLDBIT) ; 

CHKHIWRDEND (NEWWORD ,  NHtTBIT)  ; 

END;  (*  WHILE  *) 

E2D;  (*  RIGHTSHIFT  *) 


(*  ******** 
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PROCEDURE  LEFTSHIFT ( VAR  NEWWORD: 
MAXWORDS;  VAR  NEWBIT: 
I1AXBITNU1EER;  OLDWORD: 
MAXWORDS;  OLDBIT: 
MAXBITNUMBER)  ; 


BEGIN 

WHILE  (SHIFTNUM  >  0)  DO  BEGIN 
RESULT .  BIT  [  NEWWORD ,  NEWBIT] 
SHIFTNUM  :=  SHIFTNUM  -  1; 


(*  Writes  the  bit  in  RESULT  indexed  *) 
(*  by  OLDWORD  and  OLDBIT  to  ITEiTWORD  *) 
(*  and  NEWBIT.  OLDWORD  and  OLDBIT  *) 
(*  must  begin  at  the  index  value  for*) 
(*  the  most  significant  bit  to  be  *) 
(*  shifted,  and  NEWWORD  and  NEWBIT  *) 
(*  begin  at  the  index  values  for  the*) 
(*  most  significant  destination  bit.*) 
(*  Works  from  the  most  significant  *) 
(*  bit  down  and  shifts  the  number  of*) 


(*  bits  specified  by  SHIFTNUM.  *) 
(*  Changes  index  values  as  it  goes  *) 
(*  and  returns  the  final  value  of  *) 
(*  NEWWORD  and  NEWBIT.  *) 
(*  Uses  SHIFTNUM,  RESULT.  *) 
(*  Calls  CHKLONRDEND.  *) 
(*  Possible  BUGS  -  RESULT  will  need  *) 
(*  to  be  unpacked  or  masked  in  *) 
(*  Standard  Pascal.  *) 


:=  RESULT. BIT [OU3WORD, OLDBIT] ; 


CHKLCWRDEND (OLDWORD , OLDBIT) ; 
CHKLCWRDET7D  ( NEWWORD ,  NEWBIT) ; 
END;  (*  WHILE  *) 

END;  (*  LEFTSHIFT  *) 


(**********) 
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PROCEDURE  EXPFROMNUMBER(ARGUfJO:  (*  Takes  the  first  word  of  the  argument  *) 
ARGUINDEX) ;  {*  from  the  stack  and  writes  it  to  *) 

(*  WORKAREA.  Then  extracts  the  exponent*) 
(*  from  it,  writing  the  exponent  into  *) 
{*  the  appropriate  word  of  EXPVALUE.  *) 
{*  Also  extracts  the  sign  Dit  and  puts  *) 
(*  it  in  the  sign  bit  of  the  EXPVALUE  *) 
(*  indexed  2  greater  than  the  argument.  *) 
{*  Uses  EXPVALUE,  EXPLENGTH,  BITTJUM,  *) 
(*  MSBITNUM,  WORKAREA,  S,  EXPPOIOTER,  *) 
{*  SIGNMASK ,  iSORSIGBIT,  LSBITNUH,  *) 
(*  LESSIGBIT.  *) 
(*  Possible  BUGS  -  EXPVALUE  and  WORKAREA*) 
{*  will  need  to  be  unpacked  or  masked  in*) 
(*  Standard  Pascal.  *) 
(*  Known  BUGS  -  assumes  exponent  length  *) 
(*  of  no  more  than  1  bit  less  than  *) 
{*  WORDLENGIH.  *) 


VAR 

EXPBITNUM,  WQRKBITNUM:  MAXBITNUMBER; 

BEGIN 

EXPVALUE. INT[ARGUNO]  :=  0; 

EXPBITNUM  :=  EXPLE2JGTH  *  HORSIGEIT  +  LSBITNUM  +  LESSIGBIT; 
WQRKBITNUM  j=  MSBITNUIl  +  LESSIGBIT; 

WORKAREA. INT[1]  :=  S[EXPPOINTER]  ; 

FOR  BITNUH  ;=  1  TO  EXPLENGTH  DO  BEGIN 

EXPVALUE. BIT [ARGUNO , EXPBITNUM)  :=  VJORKAREA.BIT[l,WORKBnTIUH] ; 
EXPBITNUM  :=  EXPBITNUM  +  LESSIGBIT; 

W0RK3ITNUM  :=  WORKBITNUM  +  LESSIGBIT; 

END;  (*  FOR  *) 

EXPVALUE. BOOL[ARGUNO+2]  :=  WORKAREA. BOOL [1]  AND  SIGN! IASK. BOOL; 
END;  (*  EXPFROMNUMBER  *) 

(**********) 
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FUNCTION  EXPSIZE (WORDS: INTEGER) :  (*  Calculates  the  proper  sized  exponent*) 

INTEGER;  (*  for  a  real  argument  from  the  number  *) 

{*  of  words  in  the  argument  given  as  *) 
(*  the  calling  parameter.  It  assumes  *) 
(*  that  the  smallest  possible  word  size*) 
<*  is  8  bits.  It  uses  an  algorithm  *) 
(*  which  determines  the  smallest  expo-  *) 
(*  nent  length  which  can  hold  an  expo-  *) 
{*  nent  equal  to  from  +4  to  -4  times  *) 
{*  the  length  of  the  fractional  part  of*) 
(*  the  real  number  in  bits.  It  returns*) 
(*  the  number  of  bits  in  the  length  of  *) 
(*  this  smallest  exponent  as  the  value  *) 
(*  of  the  function.  *) 

{*  Uses  WQRDLENG1H.  *) 

VAR 

TRIALEXPO,  TRIALFRAC,  TRIALPRECISION,  PRECIZION:  INTEGER; 

BEGIN 

PRECIZION  :=  WORDS  *  NORDLENGTH ; 

TRIALEXPO  :=  5; 

TRIALFRAC  :=  4; 

TRIALPRECI S ION  :=  TRIALEXPO  +  TRIALFRAC  +  1; 

WHILE  (TRIALPRECISION  <  PRECIZION)  DO  BEGIN 
TRIALEXPO  :=  TRIALEXPO  +  1; 

TRIALFRAC  :=  TRIALFRAC  *  2; 

TRIALPRECISION  :=  TRIALEXPO  +  TRIALFRAC  +  1; 

EtD;  (*  WHILE  *) 

EXPSIZE  :=  TRIALEXPO; 

END;  (*  EXPSIZE  *) 

(**********) 

PROCEDURE  ARGTCWORKAREA( STACK? VORD;  (*  Writes  the  argument  on  the  *) 


IJ3TEGER) ;  (*  stack  beginning  at  *) 

(*  SfSTACKWORD]  to  WORKAREA.  *) 
(*  Uses  VJORDNUM,  NUMWORDS,  *) 
(*  WORKAREA,  S,  DOWNSTAK.  *) 


BEGIN 

FOR  WORDNUM  ;=  1  TO  NUMWORDS  DO  BEGIN 

WORKAREA.  INT[WORDNUM]  :=  SlSTACKWORDj ; 
STACKVJORD  :=  STACKWORD  +  DOWNSTAK; 

END;  (*  FOR  *) 

END;  (*  ARGTOWORKAREA  *) 

(*  **•******) 
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PROCEDURE  WRKAREATOSTACK ( STACKWORD :  (*  Takes  an  argument  from  *) 

INTEGER);  {*  \\'OPKAREA  and  puts  it  on  the  *) 

(*  stack  beginning  at  *) 

(*  S  [STACKWORD] .  *) 

(*  Uses  WORDNUM,  NUI-WQRDS,  S,  *) 

(*  KORKAREA,  DOMKSTAK.  *) 

BEGIN 

FOR  WORDNUM  :=  1  TO  HUMMDRDS  DO  BEGIN 

S[ STACKWORD]  :=  WORKAREA.  INT [WORDNUM] ; 

STACKWORD  :=  STACKTORD  +  DCMNSTAK; 

END;  (*  FOR  *) 

END;  (*  V»RKAREATOSTACK  *) 

(**★*★*****) 


PROCEDURE  Z EROCUTEXP ( WORDOFSTACK :  (*  Zeroes  out  the  sign  and  exponent  *) 
INTEGER);  (*  of  the  argument  on  the  stack  *) 

(*  starting  at  S[WORDOFSTACK] .  *) 
(*  Uses  ARITHREG,  S,  BITTOl,  *) 
(*  MSBITMUM ,  1JORDLENGTH ,  EXPLENGTH,  *) 
(*  KOUNT,  LESSIGBIT.  *) 
(*  Possible  BUGS  -  ARITHREG  v/ill  *) 
(*  need  to  be  unpacked  or  masked  in  *) 
(*  Standard  Pascal.  *) 
(*  Known  BUGS  -  assumes  the  exponent*) 
(*  to  be  no  longer  than  1  bit  less  *) 
(*  than  WORDLENGTH.  *) 


BEGIN 

ARITHREG. INT  :=  S[WQRDOFSTACK] ; 
BITNOfl  :=  MSBITMUM; 

FOR  KOUNT  :=  0  TO  EXPLENGTH  DO  BEGIN 
ARITHREG. BIT [BITNOM]  :=  FALSE; 
BITNOM  :=  BITNOM  +  LESSIGBIT; 
END;  (*  FOR  *) 

S(WORDOFSTACK]  :=  ARITHREG.  INT; 

END;  (*  ZEROOUTEXP  *) 

(**********) 
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PROCEDURE  COMPLEMENT  ( STAKMUI 1 :  (*  Complements  the  argument  on  the  stack  *) 

INTEGER);  (*  beginning  with  S [STAKNUM].  Does  not  *) 

(*  change  a  zero  argument.  *) 

(*  Uses  NUMVORDS ,  ARITHREG,  S,  NORDNUM,  *) 

(*  DONHSTAK,  UPSTAK.  *) 

VAR 

CHANGEWORD, COUNT:  INTEGER; 

BEGIN 

CHANGEiJORD  :=  STAKNUM  +  NUMWORDS  *  DCWHSTAK; 

COUNT  :=  -1; 

REPEAT 

CHANGEWORD  :=  CHANGES  70RD  +  UPSTAK; 

COUNT  :=  COUNT  +  1; 

ARITHREG. IOT  :=  S( CHANG EU3RD] ; 

UtiTIL  ((ARITHREG. IOT  <>  0)  OR  (Q1ANGENORD  =  STAKNUM) ) ; 

IF  (ARITHREG. IOT  <>  0)  THEN  BEGIN 

FOR  HORDNUN  :=  (OT1WORDS-COUNT)  DOS  MO  1  DO  BEGIN 

ARITHREG. IOT  :=  S[STAKNIJEWraRDE^l*DCV/l'STAK-HJPSTAK]  ; 

ARITHREG. BOOL  :=  NOT  ARITHREG. BOOL; 

S  [STAKNUM-rt‘JORDNUM*DCWNSTAK+UPSTAK]  :  =  ARITHREG.  IOT; 

END;  (*  FOR  *) 

S [ CHANGEWORD ]  :=  S[Q1AMGEW0KD]  +  1; 

END;  (*  IF  *) 

END;  (*  COMPLEMENT  *) 

(**********) 

PROCEDURE  EXPTONUMBER;  (*  Puts  the  sign  bit  from  SIGN  into  RESULT.  *) 


(*  Then  copies  the  exponent  value  from  *) 
(*  EXPVALUE { 1 J  into  RESULT.  *) 
(*  Uses  RESULT,  MSBITNUM,  SIGN,  EXPLENGTH,  *) 
(*  BITNUM,  EXPVALUE,  MORSIGBIT,  LSBITNUI1,  *) 
(*  LESSIGBIT.  *) 
(*  Possible  BUGS  -  RESULT,  SIGN,  and  *) 
(*  EXPVALUE  will  need  to  be  unpacked  or  *) 
(*  masked  in  Standard  Pascal.  *) 


VAR 

EXPBIT ,  RESBIT:  nAXBITTJUMBER; 

BEGIN 

RESULT . BIT [  1 , MSBITNUM ]  :=  SIGN. BIT [MSBITNUI1J  ; 

EXPBIT  :=  EXPLENGTH  *  MORSIGBIT  +  LSBITNUM  +  LESSIGBIT; 
RESBIT  :=  MSBITNUM  +  LESSIGBIT; 

FOR  BITNUM  :=  1  TO  EXPLENGTH  DO  BEGIN 

RESULT. BIT (1, RESBIT]  :=  EXPVALUE. BIT [1, EXPBIT] ; 
EXPBIT  :=  EXPBIT  +  LESSIGBIT; 

RESBIT  :=  RESBIT  +  LESSIGBIT; 

END;  (*  FOR  *) 

END;  (*  EXPIONUMBER  *) 
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PROCEDURE  DECEXP(VAR  UNDFL017:  (*  If  UNDFLOU  already  set,  it  does  *) 
BOOLEAN);  (*  nothing.  If  not,  it  decrements  the  *) 

(*  exponent  value  by  1  and  then  checks  *) 
(*  for  exponent  underflow  (negative  *) 
(*  value) .  If  found,  it  restores  2ero  *) 
(*  to  the  exponent,  sets  UNDFLOW,  and  *) 
(*  sets  SHIFTNUM  back  to  maximum  allow-  *) 


(*  able  shift.  If  no  underflow,  it  *) 
(*  increments  SHIFTNUM.  *) 
(*  Uses  EXPVALUE,  SHIFTNUM.  *) 
(*  Known  BUGS  -  assumes  the  exponent  to  *) 
(*  be  no  longer  than  one  word.  *) 


BEGIN 

IF  (UNDFLOW  =  FALSE)  THEN  BEGIN 

EXPVALUE. INT(1]  ;=  EXPVALUE. INT[1]  -  1; 
IF  (EXPVALUE. INT[1]  <  0)  THEN  BEGIN 
UNDFLOW  ;=  TRUE; 

EXPVALUE. INT[1]  :=  0; 

SHIFTNUM  ;=  SHIFTNUM  -  1; 

END  (*  IF  *) 

ELSE 

SHIFTNUM  :=  SHIFTNUM  +  1; 

END;  (*  IF  *) 

END;  (*  DEC EXP  *) 


(**★******★) 
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PROCEDURE  carryonmsb 


(*  Checks  for  exponent  overflow  and  returns  *) 
(*  an  error  if  found.  Otherwise  increases  *) 
(*  the  exponent  by  1  and  shifts  the  argument*) 


(*  in  RESULT  bv  1  to  the  right.  *) 
(*  Uses  EXPVALUE,  ERRORIND,  MORDNUM,  *) 
(*  NUMWCRDS,  BITtOH,  LSBITNUM,  NORKAREA,  *) 
(*  RESULT,  MQRSIGBIT.  *) 
(*  Calls  RIGHTSHIFT.  *) 
(*  Known  BUGS  -  assumes  exponent  is  no  more  *) 
(*  than  1  bit  less  than  WORDLEJGTH .  *) 


VAR 

WORDCNT:  MAXWORDS; 

BEGIN 

EXPVALUE . INT { 1 ]  :=  EXPVALUE. INT [1]  +  1; 

IF  (EXPVALUE. INT [1]  <  0)  THEN  BEGIN 
EXPVALUE . INT ( 1 ]  :=  EXPVALUE. INT [2] ; 

ERRORIND  :=  OVERFLOW; 

END  (*  IF  *) 

ELSE  BEGIN 

WQRDNUM  :=  NUIMORDS; 

BITNOM  :=  LSBITNUM; 

FOR  WORDCNT  :=  1  TO  NUMMORDS  DO 

WORKAREA.  IOT  [WORDCNT]  :=  RESULT.  INT  (WORDCNT)  ; 
RIGHTSHIFT  ( NUMWORDS ,  LSBITNUM+MORSIGBIT ,  WORDNUM ,  BITNOM) ; 
FOR  WORDCNT  :=  1  TO  NUMWORDS  DO 

RESULT .  INT [WORDCNT]  :=  WORKAREA.  INT  [WORDCNT]  ; 

END;  (*  ELSE  *) 

END;  (*  CARHYONMSB  *) 
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PROCEDURE  NORMiEFTSHIFT; 


(*  Checks  for  first  non  zero  bit  *) 
(*  to  determine  how  far  to  shift  *) 
(*  for  normalization.  If  all  *) 
(*  zeroes  are  found,  then  expo-  *) 
(*  nent  and  sign  are  also  zeroed  *) 
(*  out.  If  exponent  underflow  *) 
(*  occurs,  an  UNDERFLOW  error  is  *) 


(*  returned  and  the  number  *) 
(*  shifted  as  far  as  possible.  *) 
(*  Otherwise,  the  complete  nor-  *) 
(*  alization  shift  is  made  and  *) 
(*  the  exponent  is  decremented  *) 
(*  accordingly.  *) 
(*  Uses  WORDNUM,  BraOt l,  RESULT,  *) 
(*  NUMWORDS,  LSBITNUM,  EXPVALUE,  *) 
(*  SIGN,  WORDLENGTH,  EXPLQJGTH,  *) 
(*  FRACLENGTH,  SHIFTOUM,  *) 
(*  ERRORIND,  HSBITNUU,  LESSIGBIT.*) 
(*  Calls  CHKLatRDEND,  DECEXP,  *) 
(*  LEFTSHIFT.  *) 
(*  Possible  BUGS  -  RESULT  will  *) 
(*  need  to  be  unpacked  or  masked  *) 
(*  in  Standard  Pascal.  *) 


VAR 

UNDRFLOU:  BOOLEAN; 

WORDCOT:  MAXMORDS; 

BITCNT:  1 1AXBITNUI- EER ; 

BEGIN 

UNDRFLOW  :=  FALSE; 

REPEAT 

CHKLCWRD223D  (WORDNUM ,  BITIO 1)  ; 

DECEXP ( UNDRFLOW) ; 

UNTIL  ( (RESULT.  BIT  [  WORDNUM,  BITtDMj  =  TRUE)  OR  ( (WORDNUM  =  IKttDRDS)  AND 
( BIT!  DU  =  LSBITNUM) ) ) ; 

IF  ( RESULT . BIT [WORDNUM , BITNON]  =  FALSE)  THEN  BEGIN 
UNDRFLOW  :=  FALSE; 

EXPVALUE . I17T ( 1  ]  ;=  0; 

SIGN. I NT  ;=  0; 

END  (*  IF  *) 

ELSE  BEGIN 

WORDQ/T  :=  1; 

BITCNT  :=  MSBITNUM  +  (EXPLENGTH  +  1)  *  LESSIGBIT; 

SHIFT! DM  :=  FRACLENGTH  -  SHIFTNUM; 

LEFTSHIFT (WORDCNT,  BITQTT , WORD!  JUM ,  B ITNOM )  ; 

REPEAT 

RESULT. BIT[W0RDCNT,BITa7T]  :=  FALSE; 

CHKLOl7RDEND(WORDQIT,BITa]T)  ; 

UNTIL  (WORDCNT  >  NUEWORDS) ; 

ETC;  (*  ELSE  *) 

IF  (UNDRFLOW  =  TRUE)  THEN 
ERRORIND  :=  UNDERFLOW; 

E2ID ;  (*  NORMLEETSH  I  FT  *) 
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{★*★*******) 


PROCEDURE  ADDNORKALIZE;  (*  Checks  for  carry  on  the  most  significant  *) 

<*  bit,  and  if  found  calls  CARRXONNSB  for  *) 
(*  right  shift.  Otherwise  checks  for  *> 
(*  possible  left  shift  for  normalization,  *) 
{*  and  if  necessary,  calls  NORMLEFTSHIFT.  *) 
(*  Uses  WORDNUM,  BITNOM,  WORDLENGTH,  *) 
(*  EXPLENGTH,  RESULT,  SHIFTNUM,  FRACLENG1H,  *) 
(*  MSBITNUM,  LESSIGBIT.  *) 
(*  Calls  CARRXCNMSB,  CHKLCWRDEND,  *) 
<*  NORMLEFTSHIFT.  *) 
(*  Possible  BUGS  -  RESULT  will  need  to  be  *) 
(*  unpacked  or  masked  in  Standard  Pascal.  *) 


BEGIN 

WORDNUM  :=  1; 

BITNOM  :=  MSBITNUM  +  EXPLQETH  *  LESSIGBIT; 

IF  (RESULT. BIT[1, BITNOM]  =  TRUE)  THEN  BEGIN 
SHIFTNUM  :=  FRACLENGTH; 

CARRYCNMSB; 

END  (*  IF  *) 

ELSE  BEGIN 

SHIFTNUM  :=  0; 

QKLCWRDEND (VJORDNUM,  BITNOM)  ; 

IF  ( RESULT .  BIT  [WORDNUM ,  BITNOM]  =  FALSE)  THEN 
NORMLEFTSHIFT; 

END;  (*  ELSE  *) 

SID;  (*  ABNORMALIZE  *) 

(********★★) 
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PROCEDURE  RELFRACADDPREP ;  {*  Shifts  the  fractional  part  of  the  smaller  *) 

(*  number,  if  necessary,  by  the  amount  indi-  *) 
(*  cated  by  SHIFTNUM.  Zeroes  out  the  sign  *) 
(*  and  exponent  of  both  arguments.  Then  *) 
(*  complements  either  fractional  part  if  it  *) 
(*  represents  a  negative  number,  and  finally  *) 
(*  adds  the  fractional  parts,  with  the  result*) 


(*  ending  up  in  RESULT.  *) 
(*  Uses  SHIFTNUM,  EXPNUM,  STACKPOINTER,  *) 
(*  NUMWQRDS,  FRACLE2JGTH,  WORDLENGTH ,  *) 
(*  EXPLENGTH,  WORDNUM,  BITNCM,  LSBITNUM,  *) 
(*  MSBITNUM,  POINTER,  ARGUMUM,  EXPVALUE,  *) 
(*  WDPKAREA,  DCMNSTAK,  MORSIGBIT,  LESSIGBIT.  *) 
(*  Calls  ARGTCWORKAREA,  RIGHTSHIFT,  *) 
(*  WRKAREATOSTACK,  COMPLEMENT,  SIGNINTADD,  *) 
(*  ADDGENERAL,  CHKLCJWRDEND,  ZEROOUTEXP.  *) 
{*  Possible  BUGS  -  WORKAREA  will  need  to  be  *) 
(*  unpacked  or  masked  in  Standard  Pascal.  *) 


{*  Known  BUGS  -  assumes  the  exponent  is  no  *) 
(*  longer  than  1  bit  less  than  WORDLE2GTH.  *) 

VAR 

FRACWORD:  MAXWORDS; 

FRACBIT, 

STAKWORD:  INTEGER; 

BEGIN 

FRACLENGTH  :=  (NUMSVORDS  *  WORDLENGTH)  -  EXPLENGTH  -  1; 

IF  (SHIFTMUM  <>  0)  THEN  BEGIN 
IF  (EXPNUM  =  2)  THEN 

STAKWORD  ;=  STACKPOINTER 

EILSC 

STAKWORD  ;=  STACKPOINTER  +  NUI&iORDS  *  DOWKSTAK; 

ARGT0H3RKAREA  ( STAKWORD )  ; 

FRACBIT  :=  SHIFTNUM; 

FRACWORD  ;=  NUMMORDS; 

VJHILE  (FRACBIT  >  WORDLENGTH)  DO  BEGIN 
FRAGtfQRD  :*  FRACWORD  -  1; 

FRACBIT  ;=  FRACBIT  -  WORDLENGTH ; 

END;  (*  WHILE  *) 

FRACBIT  :=  LSBITNUM  +  FRACBIT  *  I-DRSIGBIT; 

SHIFTNUM  :=  FRACLENGTH  -  SHIFTNUM; 

WORDNUM  :=  NUMWORDS; 

BITNOM  :»  LSBITNUM; 

RIGHTSHIFT  ( FRACWORD ,  FRACBIT , WORDNUM ,  BITNOH) ; 

FRACWORD  ;=  1; 

FRACBIT  5*  MSBITNUM  +  EXPLENGTH  *  LESSIGBIT; 

REPEAT 

CHKLCWRDEND  ( FRACWORD ,  FRACBIT) ; 

WORKAREA . BIT [ FRACWORD , FRACBIT]  :«  FALSE; 

UNTIL  ( (FRACWORD  *  WORDNUM)  AND  (FRACBIT  =  BI'INCM) ) ; 
WRKAREATOSTAOC  (STAKWORD) ; 

EEC;  {*  IF  *) 

ZEROOUTEXP (STACKPOINTER) ; 
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Z  EROOUTEXP  ( STACKPO I  I/TER+tXJI  lK®DS*DCfrJHSrrAK )  ; 
POINTER  j«  STACKPOINTER; 

FOR  ARGUNUM  :«  2  DOWffK)  1  DO  BEGIN 

IF  ( QCIVALUE . IMT ( ARGUMJM+2 }  <  0)  THEN 
COMPLEMENT  ( POINTER) ; 

POINTER  :=*  STACKPOINTER  +  tW  WORDS  *  DCXTtlSTAK 
EW;  (*  FOR  *) 

SIGNINEADD; 

ADDGENERAL; 

EM);  (*  RELFRACADDPREP  *} 

(**********) 
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PROCEDURE  RELEXPADDPREP ;  (*  Reads  in  the  value  of  the  number  of  words  *) 

{*  in  each  argument  from  the  top  of  the  stack*) 
(*  and  determines  the  length  of  the  exponents*) 
{*  from  it.  Reads  each  exponent  into  *) 
(*  EXPVALUE  and  then  checks  to  see  which,  if  *) 
(*  either,  is  the  larger.  Sets  SHIETNUM  to  *) 
(*  the  difference  between  the  exponent  *) 
(*  values.  If  different  exponent  values,  *) 
(*  sets  EXPtUM  to  the  index  of  the  smaller  *) 
{*  exponent  (indicating  which  argument  needs  *) 
(*  to  be  shifted)  and  then  makes  both  expo-  *) 
(*  nents  equal  to  the  larger  value.  Checks  *) 
(*  for  possible  underflow  if  all  significant  *) 


(*  bits  would  be  shifted  out  of  the  number,  *) 
{*  and  returns  an  underflow  error  and  sets  *) 
(*  the  argument  equal  to  0  in  this  case.  *) 
(*  Also  checks  bits  to  be  lost  in  shifting  *) 
{*  and  returns  a  significance  warning  if  any  *) 
(*  are  l's.  *) 
(*  Uses  NUIWORDS,  S,  STACKPOIOTER,  EXPLEICIfl,*) 
(*  EXPPOINTER,  EXPVALUE,  SHIFTtIUM,  EXPNUM,  *) 
(*  POINTER,  FRACLQJG1H,  VJORDLEUGTH ,  ERRORIID,*) 
(*  WORDNUM,  BITNOfl,  LSBITNUM,  IORKAREA,  *) 
(*  MSBITNUM,  DCX'/tJSTAK,  KOUI.T,  UPSTAK,  *) 
(*  MORSIGBIT.  *) 
(*  Calls  EXPSIZE,  EXPFRQMI JUMBER .  *) 
(*  Possible  DUGS  -  KORKAREA  will  need  to  be  *) 
(*  unpacked  or  masked  in  Standard  Pascal.  *) 
(*  Known  BUGS  -  uses  only  exponents  no  longer*) 
(*  than  1  bit  less  than  HORDLENcm.  *) 


VAR 

CHECKIJUTI:  INTEGER; 

CHECKVAL;  BOOLEAN; 

BEGIN 

liUWJORDS  ;=  S  (STACK POIOTER]  ; 

STACKPOI I7TER  :=  STACKPOIOTER  +  DOWNSTAK; 

EXPLEMCTH  :=  EXPSIZE ( NtMvORDS) ; 

EXPPOINTER  :=  STACKPOI OTER; 

EXPFROMMJHBER ( 2 ) ; 

EXPPOINTER  :»  STACKPOINTER  +  NUH-CRDS  *  DO/NSTAK; 
EXPFROi  1NUI-IBER  ( 1 ) ; 

IF  (EXPVALUE. INT[1]  =  EXPVALUE. INT[ 2] )  THEM 
SHIFTNUIl  :=  0 
ELSE  BEGIN1 

IF  (EXPVALUE.INTUJ  >  EXPVALUE. II7T[2] )  THEN  BEGIN 
EXPNUH  :=  2; 

SHIFTNUM  ;=  EXPVALUE. INT(1]  -  EXPVALUE. INT (2) ; 
POINTER  :*  STACKPOItTTER; 

EXPVALUE. INT(2]  :=  EXPVALUE. INT(1] ; 

E3©  (*  IF  *) 

ELSE  BEGIN 

EXPNUM  ;  =  1  ; 

SHIFTIDM  :*  EXPVALUE. INT( 2]  -  EXPV/^LUE.IOT[1] ; 


POINTER  :=  STACKPOINTER  +  NW WORDS  *  DOMHSTAK; 
EXPVALUE.INTU)  :=  EXPVALUE.IOT[2] ; 

El©;  (*  ELSE  *) 

FRACLENGTH  :*  (NUMJORDS  *  WORDLEtGTH)  -  EXPLEJGTH  -  1? 

IF  (SHIFTNUM  >=  FRACLENGTH)  THEN  BEGIN 
SHIFT! HJM  :=  0; 

ERRORII©  :=  UNDERFLOW; 

WORDNUM  ;=  POINTER; 

FOR  ROUNT  :=  1  TO  NUHtf)RDS  DO  BEGIN 
S  [WORDNUM]  :=  0; 

WORDNUM  :=  WORDNUM  +  DOWNSTAK; 

END;  (*  FOR  *) 

B©  <*  IF  *) 

ELSE  BEGIN 

POINTER  :=  POINTER  +  NUi WORDS  *  DOWNSTAK; 

BITNOM  :=  LSBITNUM; 

CHECKNUM  :=  SHIFTNUM; 

REPEAT 

POINTER  :=  POINTER  +  UPSTAK; 

WORKAREA.IOT(l)  :=  S[POINTER]; 

REPEAT 

CHEQCVAL  :=  WORKAREA. BIT [1, BITNOM ] ; 

CHECKNUM  :=  CHECKNUM  -  1; 

BITNOM  ;=  BITNOM  +  MORSIGBIT; 

UNTIL  ({CHECKVAL  =  TRUE)  OR  {CHECKNUM  =  0)  OR 

( ( (BITNOM  >  MSBITNUM)  At©  (MORSIGBIT  =  1) )  OR 
( (BITNOM  <  MSBITNUM)  At©  (MORSIGBIT  =  -1) ) ) ) ; 
BITtCM  :=  LSBITNUM; 

UNTIL  ((CHECKVAL  ■  TRUE)  OR  (CHECKNUM  =  0))  ; 

IF  (CHECKVAL  »  TRUE)  THEN 

ERRORII©  :=  SIGNIFICANCELOST; 

END;  (*  ELSE  *) 

END;  (*  ELSE  *) 

END;  (*  RELEXPADDPREP  *) 

(»***★*****) 


PROCEDURE  PUSHRESULT;  (*  Takes  the  argument  from  RESULT  and  places  *) 

(*  it  on  the  stack  starting  at  the  position  above*) 
<*  that  pointed  to  by  STACKPOINTER.  Leaves  *) 
(*  STACKPOIOTER  pointing  to  the  first  word  of  the*) 
(*  argument  (top  of  the  stack) .  *) 

(*  Uses  WORDNUM,  NUMWORDS,  STACKPOINTER,  S,  *) 

(*  RESULT,  UPSTAK.  *) 

BEGIN 

FOR  WORDMJM  :«  NUM*iORDS  DCWNIO  1  DO  BEGIN 
STACKPOINTER  :=  STACKPOIOTER  +  UPSTAK; 

SI  STACKPOINTER)  :«  RESULT.  IOT  (WORDNUM) ; 

BD;  (*  FOR  *) 

END;  (*  PUSHRESULT  *) 

(*****♦***♦) 


120 


PROCEDURE  CHKINTADD;  {*  Checks  SIGHINDICATOR  to  see  if  the  result  is  *) 

(*  supposed  to  have  the  same  sign  as  SIGN.  If  *) 
(*  so,  it  checks  the  signs  and  if  they  don't  *) 
(*  match,  it  sets  ERRORIND  to  indicate  an  *) 
(*  overflow  and  then  sets  the  sign  back  to  the  *) 
(*  correct  value.  *) 
(*  Uses  SIGHINDICATOR,  RESULT,  MSBITNUM,  SIGN,  *) 
(*  ERRORIND,  SIGNMASK.  *) 
(*  Possible  BUGS  -  RESULT  and  SIGN  will  need  to  *) 
(*  be  unpacked  or  masked  in  Standard  Pascal.  *) 


BEGIN 

IF  (SIGHINDICATOR  =  SAME)  THEN  BEGIN 

IF  (RESULT. BIT [1, MSBITNUM]  <>  SIGN. BIT [MSBITNUM])  THEN  BEGIN 
ERRORIND  :=  OVERFLOW; 

RESULT. BOOL[1]  :=  SIGN. BOOL  OR  (RESULT.BOOL[1]  AND  MOT 
SIGNMASK. BOOL)  ; 

END;  (*  IF  *) 

END;  (*  IF  *) 

END;  (*  CHKINTADD  *) 


(★****★****) 


PROCEDURE  CHKRELADD;  (*  Complements  the  resultant  fractional  part  *) 

(*  if  negative,  then  normalizes  the  frac-  *) 
(*  tional  part  and  fills  in  the  sign  and  *) 
(*  exponent  to  complete  the  final  result  in  *) 
(*  RESULT.  *) 
(*  Uses  SIGN,  RESULT,  MSBITNUM,  STACKPOI17TER , * ) 
(*  MUM’JORDS,  WORDNUM,  S,  DONNSTAK.  *) 
(*  Calls  PUSHRESULT,  CCHPLQiENT,  EXPTONUMBER,*) 
(*  ADDNORMALIZE.  *) 
(*  Possible  BUGS  -  SIGN  and  RESULT  will  need  *) 
(*  to  be  unpacked  or  masked  in  Standard  *) 
(*  Pascal.  *) 


BEGIN 

SIGN. BIT (MSBITNUM]  ;=  RESULT. BIT [1, MSBITNUM] ; 

IF  (RESULT. INT[1)  <  0)  THIN  BEGIN 
PUSHRESULT; 

COi  1PLO-1ENT  ( STACKPOINTER)  ; 

FOR  WORDNUM  :=  1  TO  NUMMDRDS  DO  BEGIN 

RESULT.il/TlVjORDNUH]  :=  S  [STACKPOINTER]  ; 
STACKPOINTER  :=  STACKPOINTER  +  DCXjNSTAK; 
END;  (*  FOR  *) 

END;  (*  IF  *) 

ADDNORMALIZE; 

EXPTONUMBER; 

END;  (*  CHKRELAEO  *) 

(****♦****★) 
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PROCEDURE  MASK IN IT; 


(*  Initializes  BYTEMASK  -  byte  1  is  all  zeroes  *) 
(*  and  byte  0  is  all  ones.  Also  initializes  *) 
(*  SIGNMASK  with  a  1  in  the  sign  bit  and  the  *) 
(*  rest  zeroes.  *) 

(*  Uses  BYTEMASK,  SIGII1ASK,  BITNUI1,  VDRDLEUGIH , *) 
(*  BYTESIZE.  *) 

BEGIN 

BYTEMASK.  INT  :«  BYTESIZE; 

SIGNMASK. INT  :=  1; 

FOR  BITNUI'I  :=  1  TO  (KORDLEMGTO  -  1)  DO 
SIGiMASK.INT  :=  2  *  SIGJMASK.INT; 


END;  (*  MASKINIT  *) 


l 
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(****************************************************************************) 


{ **************************************************************************** j 
(*  *) 
(*  IMPLMENT  "FUNCTIONS"  *) 
<*  *) 
( ****************************************************************************  j 


PROCEDURE  INTADD;  {*  Adds  two  integers  which  are  on  the  stack  pre-  *) 

(*  ceded  by  an  integer  word  which  indicates  the  *) 
(*  number  of  words  in  each  integer  argument.  *) 
(*  Places  the  result  back  on  the  top  of  the  stack.*) 

(*  Uses  no  variables.  *) 

{*  Calls  INTPREPADD,  CHKINTADD.  *) 

BEGIN 

INTPREPADD; 

CHKINTADD; 

END;  (*  INTADD  *) 

(**********) 


PROCEDURE  RELADD;  (*  Adds  two  reals  which  are  on  the  stack  preceded  *) 

(*  by  an  integer  word  which  indicates  the  number  *) 
(*  of  words  in  each  real  argument.  Places  the  *) 
(*  result  back  on  the  top  of  the  stack.  *) 

(*  Uses  no  variables.  *) 

(*  Calls  RELFRACADDPREP,  RELEXPADDPREP ,  *) 

(*  CHKRELADD.  *) 

BEC-IN 

RELEXPADDPREP; 

RELFRACADDPREP; 

CHKRELADD; 

END;  (*  RELADD  *) 


{*  *********) 


PROCEDURE  INU-IULT; 

BEGIN 

END;  (*  INU-IULT  *) 

{**********) 


PROCEDURE  RELMULT; 

BEGIN 

END;  (*  RELNULT  *) 

(**********) 
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PROCEDURE  INTDIV; 
BEGIN 

END;  (*  INTDIV  *) 


{**********) 


PROCEDURE  RELDIV; 
BEGIN 

END;  (*  RELDIV  *) 
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(*****************************«** ********************************************^ 
(A***************************************************************************) 


(*******************************************«********************************J 
(*  *) 
(*  MAIN  IMPLMEOT  EXECUTION  *) 
<*  *) 
( *************************** ************************************************* j 


BEGIN 

MASKINIT; 

ERRORIND  :=  t  OERROR? 

CASE  FNCTCCNCODE  OF 
1:  IOTADD; 

2:  RELADD; 

3:  IOTIULT; 

4:  RELMULT; 

5:  INTO IV; 

6:  RELDIV; 

El  ID;  (*  CASE  *) 

PUSHRESULT; 

IF  (ORD  ( ERRORIND)  >  0)  THIN 

ERRORCODE  s-  ORD(ERRORIND) ; 

END;  (*  IMPLMQJT  *} 


f**************************************************************************** 
(**************•**********************************************************•**) 
{**  **) 

(**  END  I  M  P  L  M  E  II  T  **) 

{** 

(A******************************************************.*********************) 
( *********•***************••**••***»**•**•**«***•******«***•*•*•****•********) 
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